Software Engineering: Capturing Requirements Lecture Notes PDF

Software Engineering Chapter 4 Capturing Requirements 1  Chapter 4 Objectives Eliciting requirements from the customers Modeling requirements Reviewing requirements to ensure their quality Documenting requirements for use by the design...

Software Engineering Chapter 4 Capturing Requirements 1  Chapter 4 Objectives Eliciting requirements from the customers Modeling requirements Reviewing requirements to ensure their quality Documenting requirements for use by the design and test teams * Software Engineering 2  The Requirement Process When customer request a new system – Replacing an existing system – Changing the way things are done (manual to automatic) E.g. Paying bills A requirement is an expression of desired behaviour A requirement deals with – objects or entities – the state they can be in – functions that are performed to change status or object characteristics E.g. suppose you are building a system to generate paychecks for our customer's company. The requirements are : – Checks are to be issued every two weeks – Direct deposit of an employee’s check is to be allowed for every employee at certain salary level – The customer may request access to paycheck system from several different company locations * Software Engineering 3  The Requirement Process (cont.) We look at the requirements that: – Identify key entities (“an employee is a person who is paid by the company”) – Limit entities (“an employee may be paid for no mare than 40 hours per a week”) – Define the relationship among entities (“an employee X is supervised by employee Y so Y can authorized a change to X’s salary”) Requirements focus on the customer needs, not on the solution or implementation – designate what behavior, the customer needs without saying how that behaviour will be realized * Software Engineering 4  Why Are Requirements Important? Top factors that caused project to fail: - Incomplete requirement - Lack of user involvement - Unrealistic expectations - Lack of executive support - Changing requirements and specifications - Lack of planning - System no longer needed Some part of the requirements process is involved in almost all of these causes Requirements error can be expensive if not detected early -if it cost 1$ to find and fix problem during requirement definition process ,it will cost 5$ to repair it during design, 10$ during coding, 20$ during unit test, as much as 200$ after delivery of the system * Software Engineering 5  Process for Capturing Requirements Performed by the req. analyst or system analyst As req. analyst we follow this routine: – Work with customer to elicit the requirements by asking questions ,examining current behavior, or demonstrate similar systems – We capture the requirements in a model or prototype (this help us to better understand the required behavior) – Once the requirements are well understood, we progress to the specification phase, in which we decide which parts of the required behavior will be implemented in software – During validation , we check that our specification matches what the customer expects to see in the final product – Analysis and validation activities may expose problems or omission in specification that cause us to revisit the costumer and revise our models and specification. * Software Engineering 6  Process for Capturing Requirements The final outcome is a Software Requirements Specification (SRS) document which are used to communicate to other software developers( designers ,testers, maintainers) * Software Engineering 7  Requirements Elicitation Customers do not always understand what their needs and problems are It is important to discuss the requirements with everyone who has a stake in the system Come up with agreement on what the requirements are – If we can not agree on what the requirements are, then the project is doomed to fail * Software Engineering 8  Requirement Stakeholders Clients: pay for the software to be developed Customers: buy the software after it is developed Users: use the system Domain experts: familiar with the problem that the software must automate (e.g. financial expert) Market Researchers: conduct surveys to determine future trends and potential customers Lawyers or auditors: familiar with government, safety, or legal requirements Software engineers or other technology experts * Software Engineering 9  Means of Eliciting Requirements Interviewing stake holders Reviewing available documentations Observing the current system (if one exists) Apprenticing with users to learn about user's task in more details Interviewing user or stakeholders in groups, so that they will be inspired by one another‘s ideas Brainstorming with current and potential users about how to improve the proposed product. * Software Engineering 10  Means of Eliciting Requirements (cont.) * Software Engineering 11  Types of Requirements 1. Functional requirement: describes required behavior in terms of required activities, such as reactions to inputs, and the state of each entity before and after an activity occurs. 2. Quality requirement or nonfunctional requirement: describes some quality characteristic that the software must possess, such as fast response time, ease of use, high reliability, or low maintenance cost 3. Design constraint: a design decision such as choice of platform or interface components * Software Engineering 12  Resolving Conflicts Different stakeholder has different set of requirements – potential conflicting ideas Need to prioritize requirements Prioritization might separate requirements into three categories – essential: absolutely must be met – desirable: highly desirable but not necessary – optional: possible but could be eliminated E.g. the credit card billing system : It must be able to list current charges, sum them, and request payment by a certain date (essential requirements) It may also separate the charges by purchase type (desirable), It may print the credits in black and the debits in red (optional) * Software Engineering 13  Kinds of Requirements Documents Requirements definition: a complete listing of everything the customer wants to achieve. – Describing the entities in the environment where the system will be installed. – The requirements are written entirely in terms of the environment, describing how the environment will be affected by the proposed system. – Requirements definition is amid at a business audience, such as client, customer and user. Requirements specification: restates the requirements as a specification of how the proposed system shall behave – It is written entirely in terms of the environment, except that it refers only to environmental entities that are accessible to the system via its interface – Specification restricted only to the intersection between environment and system domain – Requirements specification is amid at a technical audience, such as designer, tester, and project manager. * Software Engineering 14  Kinds of Requirements Documents * Software Engineering 15  Characteristics of requirements Correct Consistent Unambiguous Complete Feasible Relevant Testable Traceable Software Engineering  Modeling Notations It is important to have standard notations for modeling, documenting, and communicating decisions There are many modeling notation: – Entity-Relationship Diagrams – Data-Flow Diagrams * Software Engineering 17  Entity-Relationship Diagrams A popular graphical notational paradigm for representing conceptual models Has three core constructs – An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviors – A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying the type of relationship – An attribute: an annotation on an entity that describes data or properties associated with the entity ER diagrams are popular because – they provide an overview of the problem to be addressed – the view is relatively stable when changes are made to the problem's requirements ER diagram is likely to be used to model a problem early in the requirements process * Software Engineering 18  Entity-Relationship Diagrams (cont.) Entity diagram of turnstile problem * Software Engineering 19  Data-Flow Diagrams ER diagram describe only lower-level behaviours A data-flow diagram (DFD) models functionality shows the flow of data from one function to another – A bubble represents a process – An arrow represents data flow – A data store: a formal repository or database of information – Rectangles represent actors: entities that provide input data or receive the output result * Software Engineering 20  A high-level data-flow diagram for the library problem * Software Engineering 21