Requirements Engineering Week 1 & 2 Introduction Dr. Eman Al-Maghary

Agenda Software Lifecycle and Software Processes Introduction to RE

Engineering Character of Software Development Large software development project requires an Engineering approach: Life-Cycle Teamwork Requires an overall plan, organization and communication

Some Process Models Waterfall RUP: Specialized: Formal Methods Incremental Iterative Specialized: Formal Methods

The Linear (Waterfall) Model Modeled after a conventional engineering cycle Assumes that a complete system will be delivered after the linear sequence is completed Problems: customer has to sate all requirements explicitly; doesn’t support change; customer can see a working version of the program until code phase. old fashioned but reasonable approach when requirements are well understood

Waterfall Model: Discussion Assumes that a complete system will be delivered after the linear sequence is completed Problems: customer has to state all requirements explicitly; doesn’t support change; customer can’t see a working version of the program until code phase.

Rational Unified Process (RUP)

“Mini-Waterfall” Process RUP Iteration Process Inception Elaboration Construction Transition Iteration 1 Iteration 2 Iteration 3 “Mini-Waterfall” Process Iteration Planning Rqmts Capture Analysis & Design Implementation Test Prepare Release

Unified Process: Iterative Life Cycle Main reason for using the iterative life cycle: You do not have all the information you need up front Things will change during the development period

Phases in the RUP Inception: group the project’s risks by building a proof of concept. Establish a business case of the system. Identify external entities (people and systems) that will interact with the system and define these interactions. Access contribution to the system. Elaboration: Develop a common understanding of the system’s scope and desired behavior Address system-wide issues (activities and resources) Elaboration: Architectural framework of the system, Project plan, identify key project risks On the completion of this phase u should have: a requirements model(use case), an architectural description and a development plan for the software

Phases in the RUP(Cont.) Construction: build the product Risk-Driven iterations Continuous integration (concerned with system design, programming and testing) Transition: deliver the product to the user’s community Facilitate user acceptance Measure user satisfaction

Selecting Iterations The first iteration: Be modest regarding the amount of functionality that can be achieved in the first iteration Teams new to an iterative approach are usually overoptimistic How many iterations do I need? On projects taking 18 months or less, 3 to 6 iterations are typical

Iteration Assessment Assess iteration results (functionality, performance, quality) Consider external changes that have occurred during this iteration (changes to requirements, changes to user needs, competitor plans) Determine what rework is required and assign it to the remaining iterations

RUP: Key points Defines the function of the system from the user point of view applying scenario-based approach. Uses Unified Modeling Language (UML): industrial standard notation Rational: a software tools supporting UP and UML, used widely in industry Unified Software Development Process (UP) is representative of CBD models that are used in industry.

Modeling: Bridge between Requirements and Solution Modeling a system involves: identifying the things that are important to your particular view Their properties consider how specific instances of these things must fit together. Modeling a system is affected by how you expect to use the system Example: NEXT These things are from the vocabulary of the system you are modeling. For example, if you are building a house , things like walls, doors, windows, cabinets, and lights are some of the things that will be important to a home owner. Each of these things can be distinguished from the other. Each of them has a set of properties. Walls have a height and a width and are solid. Doors also have a height and width and are solid, as well, but have the additional behavior that allows them to open in one direction. Windows are similar to doors have slightly different properties. Windows are usually (but not always) designed so that you can get out of them instead of pass through them. Individual walls, doors, and windows rarely exist in isolation, so you must also consider how specific instances of these things must fit together. The things you identify and the relationships you choose to establish among them will be affected by how you expect to use the various room to room, and the general style and feel you want this arrangement to create. . Users will be concerned about different things. For example, the plumbers who help build your house will be interested in things like drains, traps, and vents. You, as a home owner, won’t necessarily care about these things except in so far as they interact with the things in your view, where a drain might be placed in a floor or where a vent might intersect with the roof line.

Requirements Gathering: Dice Game Requirements gathering is the Starting Point (WHAT, i.e., problem oriented) Dice Game: A player plays the dice game the dice game includes two dice. A player rolls two dice. If the total is seven, the player wins; otherwise the player loses.

How Do You Expect to Use the Dice Game ? “Happy end” scenario User: I want to play this game. Dice Game: Roll two dice. System: CONGRATULATIONS! You won the game.

How Do You Expect to Use the Dice Game ? Not so “happy end” scenario User: I want to play this game. Dice Game: Roll two dice. System: Looser, try again …

Modeling: Dice Game Dice Game: A player plays the dice game Modeling Features: Dice Game: A player plays the dice game the dice game includes two dice. A player rolls two dice. If the total is seven, the player wins; otherwise the player loses. Play with two dice

Modeling: Dice Game Modeling Structure Rolls Plays Includes Player name 1 2 Die FaceValue highly-creative activity. It’s hard to measure a good design objectively 1 2 Plays DiceGame total 1 1 Includes

Modeling: Dice Game Modeling Behavior : DiceGame Die1: Die Die2:Die Play() GetFaceValue() roll() Total() Result() highly-creative activity. It’s hard to measure a good design objectively

Modeling Requirements: Requirements Specifications Definition: “Specifications represent a model of how inputs are related to system reactions and outputs” Specification is an ABSTRACTION of the Requirements Specifications will increase the technical level of details given in the requirements

Modeling of The Problem: Problems? Abstraction might capture only part of the real world truth (i.e., incomplete) A book may have more than one writers Somebody else is paid to write the book … Domain Knowledge is required Complexity of the Problem is an issue

Software Complexity Large and Complex software systems: Complex: Overall Behavior can only be predicted with some degree of uncertainty Large: systems built with a large number of components Size complexity: the vast amount of information to be gathered and analyzed during the requirements & specification stage may cause incorrect and incomplete specification Other sources for complexity: Environmental complexity Problem domain complexity Communication complexity Simple software systems: Characterized by total predictability and small size

Specialized Process Models: The Formal Methods Model Formal method— process to apply when a mathematical specification is to be developed Enable software engineers to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation. Offers (the promise of) defect-free software Training is required Cleanroom software engineering—emphasizes error detection before testing. Currently applied in industry.

Software Engineering: Key Points SE: A discipline for the systematic production and maintenance of software developed by a team, which is fault-free, delivered on time, within budget, and satisfies the user’s needs GOAL: to produce a good quality software that is useful for people

Agenda Software Lifecycle and Software Processes Introduction to RE

What is a Good Quality Software? A software is good if it MEETS CUSTOMERS EXPECTATIONS: it is (at least) correct, reliable, maintainable, user-friendly … the total cost it incurs over all phases of its life cycle is minimal and within the budget

Why Comprehension of User Requirements is Important? RE objectives: Unambiguous, complete and consistent problem documentation. Barriers to requirements elicitation “Yes, But” syndrome “The Undiscovered Ruins” syndrome “The User and The Developer” syndrome Techniques: interviews, workshops, storyboards Rely on individual’s ability in communicating with the stakeholders

Stakeholders in SE Customers Users Software developers Those who pay for the software Users Those who use the software Software developers Development Managers

Stakeholder Needs (extracted from the slides of Peter Hauker, Rational)

Features of the System (extracted from the slides of Peter Hauker, Rational)

Software Requirements (extracted from the slides of Peter Hauker, Rational)

How Do We … ? … know what the system is supposed to do? By proper requirements development … keep track of the current status of requirements? … determine the impact of a requirements change? By proper requirements management

Requirements Engineering: General View

Requirements Development Process Elicitation: work with the customer on gathering requirements Analysis: process this information to understand it, classify in various categories, and relate the customer needs to possible software requirements Specification: Structure the customer input and derived requirements as written documents and diagrams Validation: you’ll ask your customer to confirm that what you’ve written is accurate and complete and to correct errors. This iterative process continues throughout requirements development No single formulaic approach to requirements development. Structure the customer input and derived requirements as written documents and diagrams process this information to understand it, classify in various categories, and relate the customer needs to possible software requirements work with the customer on gathering requirements you’ll ask your customer to confirm that what you’ve written is accurate and complete and to correct errors

Requirements Development Process Elicitation: work with the customer on gathering requirements Analysis: process this information to understand it, classify in various categories, and relate the customer needs to possible software requirements Specification: Structure the customer input and derived requirements as written documents and diagrams Validation: you’ll ask your customer to confirm that what you’ve written is accurate and complete and to correct errors. This iterative process continues throughout requirements development, No single formulaic approach to requirements development.

Software-Intensive Systems Software (on its own) is useless Software is an abstract description of a set of computations Software only becomes useful when run on some hardware we sometimes take the hardware for granted Software + Hardware = “Computer System” A Computer System (on its own) is useless Only useful in the context of some human activity that it can support we sometimes take the human context for granted

Software-Intensive Systems (cont.) A new computer system will change human activities in significant ways Software + Hardware + Human Activities = “Software-Intensive System” ‘Software’ makes many things possible It is complex and adaptable It can be rapidly changed on-the-fly It turns general-purpose hardware into a huge variety of useful machines

Quality = Fitness for purpose Software technology is everywhere Affects nearly all aspects of our lives But our experience of software technology is often frustrating/disappointing Software is designed for a purpose If it doesn’t work well then either: …the designer didn’t have an adequate understanding of the purpose …or we are using the software for a purpose different from the intended one Requirements analysis is about identifying this purpose Inadequate understanding of the purpose leads to poor quality software

Quality = Fitness for purpose (cont.) The purpose is found in human activities E.g. Purpose of a banking system comes from the business activities of banks and the needs of their customers The purpose is often complex: Many different kinds of people and activities Conflicting interests among them

Complexity of Purpose People and software are closely-coupled Complex modes of interaction Long duration of interaction Mixed-initiative interaction Socially-situated interaction …software systems and human activity shape each other in complex ways The problems we’d like software to solve are “wicked” No definitive formulation of the problem No stopping rule (each solution leads to new insights) Solutions are not right or wrong No objective test of how good a solution is (subjective judgment needed) Each problem is unique (no other problem is exactly like it) Each problem can be treated as a symptom of another problem Problems often have strong political, ethical or professional dimensions

Dealing with problem complexity Abstraction Ignore detail to see the big picture Treat objects as the same by ignoring certain differences (beware: every abstraction involves choice over what is important) Decomposition Partition a problem into independent pieces, to study separately (beware: the parts are rarely independent really)

Dealing with problem complexity (cont.) Projection Separate different concerns (views) and describe them separately Different from decomposition as it does not partition the problem space (beware: different views will be inconsistent most of the time) Modularization Choose structures that are stable over time, to localize change (beware: any structure will make some changes easier and others harder)

Definition of RE Requirements Engineering (RE) is a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software intensive technologies.

Cost of getting it wrong Cost of fixing errors Typical development process: requirements analysis ⇒ software design ⇒ programming ⇒ development testing ⇒ acceptance testing ⇒ operation Errors cost more to fix the longer they are undetected E.g. A requirements error found in testing costs 100 times more than a programming error found in testing Causes of project failure Survey of US software projects by the Standish group: Top 3 success factors: 1) User involvement 2) Executive management support 3) Clear statement of requirements Top 3 factors leading to failure: 1) Lack of user input 2) Incomplete requirements & specs 3) Changing requirements & specs

Requirements Problems Requirements don’t reflect real needs of the customer Requirements are inconsistent and/or incomplete It is expensive to make changes to requirements after they have been agreed There are misunderstandings between customers and developers

Requirements Phase The requirements phase: Elicitation of systems requirements as specified by the user Review of these requirements for ambiguities and inconsistencies Transformation of the requirements to a description of what the software will do without describing how it will do it.

System Requirements Elicitation Elicitation of accurate requirements is important because The later in the development life cycle that a software error is detected, the more expensive it will be to repair Many errors remain latent and are not detected until well after the phase during which they are made Many requirement errors are made

Requirements Document Formal document used to communicate requirements to customers, engineers and managers Serves as the baseline for the system Must be formally changed via a change control process IEEE Std. 830: 1998 (I will email it to you)

Requirements Document Describes the following services and functions of the system system constraints emergent properties identification of system integration to other systems domain information development process constraints