M L UN P CORT S,M A,M A,B EJ     .    E B     P SCSSoftware Engineering: A Practitioner’s Approach, 6/e            Chapter...
Requirements Engineering    Stages:        Inception        Elicitation        Elaboration        Negotiation       ...
Requirements Engineering   Inception—ask a set of questions that establish …        basic understanding of the problem  ...
Requirements Engineering   Elaboration—create an analysis model that identifies data,    function, features, constraints ...
Requirements Engineering   Specification—can be any one (or more) of the following:        A written document        A ...
Requirements Engineering   Requirements management involves managing change:       Feature traceability: how requirement...
Inception   Identify stakeholders       “whom else do you think I should talk to?”   Recognize multiple points of view...
Inception   The subsequent questions:       What constitutes a “good” output from the system?       What problem(s) doe...
Inception   The final questions:       Are your answers official?       Are my questions relevant?       Am I asking t...
Eliciting Requirements   Meetings are conducted and attended by both software engineers    and customers   Rules for pre...
Conduc t FA ST                                                    m eet ings                                              ...
Quality Function Deployment   A technique of translating customer needs into technical    system requirements:   Normal ...
Quality Function Deployment   Function deployment determines the “value” (as    perceived by the customer) of each functi...
Elicitation Work Products   A statement of need and feasibility.   A bounded statement of scope for the system or produc...
Use-Cases   A collection of user scenarios that describe the thread of usage of a system   Each scenario is described fr...
Use-Case Diagram                     Arms/ disarms                        syst em                  Accesses syst em       ...
Building the Analysis Model   Intent: to provide a description of the required    informational, functional and behaviora...
Building the Analysis Model   Elements of the analysis model       Scenario-based elements            Functional—proces...
Class DiagramFrom the SafeHome system …           Sensor     name/id     type     location     area     characteristics   ...
State Diagram                                                                                 Reading                     ...
Analysis PatternsPattern name: A descriptor that captures the essence of the pattern.Intent: Describes what the pattern ac...
Negotiating Requirements   Identify the key stakeholders       These are the people who will be involved in the        n...
Validating RequirementsChecking for Consistency, Omissions, Ambiguity    Is each requirement consistent with the overall ...
Validating Requirements   Is each requirement achievable in the technical environment that will house    the system or pr...
Upcoming SlideShare
Loading in …5
×

MELJUN CORTES Software Eng'g Chapter4

360 views

Published on

MELJUN CORTES Software Eng'g Chapter4

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
360
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

MELJUN CORTES Software Eng'g Chapter4

  1. 1. M L UN P CORT S,M A,M A,B EJ . E B P SCSSoftware Engineering: A Practitioner’s Approach, 6/e Chapter 4: Requirements Engineering 1
  2. 2. Requirements Engineering  Stages:  Inception  Elicitation  Elaboration  Negotiation  Specification  Validation  Management 2
  3. 3. Requirements Engineering Inception—ask a set of questions that establish …  basic understanding of the problem  the people who want a solution  the nature of the solution that is desired, and  the effectiveness of preliminary communication and collaboration between the customer and the developer Elicitation—elicit requirements from all stakeholders  address problems of scope  address problems of understanding  customers not sure about what is needed, skip “obvious” issues, have difficulty communicating with the software engineer, have poor grasp of problem domain  address problems of volatility 3
  4. 4. Requirements Engineering Elaboration—create an analysis model that identifies data, function, features, constraints and behavioral requirements Negotiation—agree on a deliverable system that is realistic for developers and customers  rank requirements by priority (conflicts arise here …)  identify and analyze risks assoc. with each requirement  “guestimate” efforts needed to implement each requirement  eliminate, combine and / or modify requirements to make project realistic 4
  5. 5. Requirements Engineering Specification—can be any one (or more) of the following:  A written document  A set of models  A formal mathematical model  A collection of user scenarios (use-cases)  A prototype Validation—a review mechanism that looks for:  errors in content or interpretation  areas where clarification may be required  missing information  inconsistencies (a major problem when large products or systems are engineered)  conflicting or unrealistic (unachievable) requirements 5
  6. 6. Requirements Engineering Requirements management involves managing change:  Feature traceability: how requirements relate to observable system/product features  Source traceability: identifies source of each requirement  Dependency traceability: how requirements are related to each other  Subsystem traceability: categorizes requirements by the subsystem(s) they govern  Interface traceability: how requirements relate to both external and internal system interfaces 6
  7. 7. Inception Identify stakeholders  “whom else do you think I should talk to?” Recognize multiple points of view Work toward collaboration The first questions:  Who is behind the request for this work?  Who will use the solution?  What will be the economic benefit of a successful solution?  Is there another source for the solution that you need? 7
  8. 8. Inception The subsequent questions:  What constitutes a “good” output from the system?  What problem(s) does this solution address?  What is the intended business environment for this solution?  What performance issues or constraints should affecting my approach to the solution 8
  9. 9. Inception The final questions:  Are your answers official?  Are my questions relevant?  Am I asking too many questions?  Can anyone else provide additional info?  Should I be asking anything else? 9
  10. 10. Eliciting Requirements Meetings are conducted and attended by both software engineers and customers Rules for preparation and participation are established An agenda is suggested A "facilitator" (can be a customer, a developer, or an outsider) controls the meeting A "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used The goal is  to identify the problem  propose elements of the solution  negotiate different approaches, and  specify a preliminary set of solution requirements 10
  11. 11. Conduc t FA ST m eet ings Mak e list s of f unct ions , c las s es Mak e list s of c ons t raint s , et c . f orm al priorit iz at ion?El i c i t re q u i re m e n t s y es no Us e QFD t o inf orm ally def ine ac t ors priorit iz e priorit iz e requirem ent s requirem ent s draw us e-c as e writ e sc enario diagram Creat e Use-c as es c om plet e t em plat e 11
  12. 12. Quality Function Deployment A technique of translating customer needs into technical system requirements: Normal requirements: reflect stated customer goals and objectives Expected requirements: implicit to the product or system; their absence will cause significant customer dissatisfaction Exciting requirements: featured going beyond customer expectations, causing customer euphoria (;-) 12
  13. 13. Quality Function Deployment Function deployment determines the “value” (as perceived by the customer) of each function required of the system Information deployment identifies data objects and events Task deployment examines the behavior of the system Value analysis determines the relative priority of requirements 13
  14. 14. Elicitation Work Products A statement of need and feasibility. A bounded statement of scope for the system or product. A list of customers, users, and other stakeholders who participated in requirements elicitation A description of the system’s technical environment. A list of requirements (preferably organized by function) and the domain constraints that apply to each. A set of usage scenarios that provide insight into the use of the system or product under different operating conditions. Any prototypes developed to better define requirements. requirements 14
  15. 15. Use-Cases A collection of user scenarios that describe the thread of usage of a system Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way Each scenario answers the following questions:  Who is the primary actor, the secondary actor (s)?  What are the actor’s goals?  What preconditions should exist before the story begins?  What main tasks or functions are performed by the actor?  What extensions might be considered as the story is described?  What variations in the actor’s interaction are possible?  What system information will the actor acquire, produce, or change?  Will the actor have to inform the system about changes in the external environment?  What information does the actor desire from the system?  Does the actor wish to be informed about unexpected changes? 15
  16. 16. Use-Case Diagram Arms/ disarms syst em Accesses syst em sensor s via Int ernet homeow ner Responds t o alarm event Encount er s an error condit ion syst em Reconf igures sensorsadminist rat or and relat ed syst em f eat ures 16
  17. 17. Building the Analysis Model Intent: to provide a description of the required informational, functional and behavioral domains of the computer-based system The model changes dynamically as the system engineers learn more about the system Is a series of time-ordered snapshots of requirements 17
  18. 18. Building the Analysis Model Elements of the analysis model  Scenario-based elements  Functional—processing narratives for software functions  Use-case—descriptions of the interaction between an “actor” and the system  Class-based elements  Implied by scenarios  Behavioral elements  State diagram  Flow-oriented elements  Data flow diagram 18
  19. 19. Class DiagramFrom the SafeHome system … Sensor name/id type location area characteristics identify() enable() disable() reconfigure() 19
  20. 20. State Diagram Reading Init ializat ion commands not jammed t urn copier subsyst ems syst em st at us=“not ready” syst em st at us=“ Ready” paper f ull “on“ ready display msg = “please wait ” display msg = “ ent er cmd” display st at us = blinking display st at us = st eady ent ry/ swit ch machine on ent r y/ subsyst ems r eady do: run diagnost ics do: poll user input panel do: init iat e all subsyst ems do: read user input do: int erpret user input t urn copier “of f ” st ar t copies Making copies load paper copies complet esyst em st at us=“Copying” syst em st at us=“ load paper ”display msg= “copy count =” display msg= “load paper”display message=#copies paper t ray empt y display st at us= blinkingdisplay st at us= st eadyent ry/ st art copies paper jammed ent ry/ paper empt ydo: manage copying do: lower paper t raydo: monit or paper t ray do: monit or f ill swit chdo: monit or paper f low problem diagnosis do: r aise paper t ray syst em st at us=“Jammed” display msg = “ paper jam” display message=locat ion display st at us= blinking not jammed ent ry/ paper jammed do: det ermine locat ion do: provide correct ivemsg. do: int err upt making copies Figure 7.6 Preliminary UML st at e diagram for a phot ocopier 20
  21. 21. Analysis PatternsPattern name: A descriptor that captures the essence of the pattern.Intent: Describes what the pattern accomplishes or representsMotivation: A scenario that illustrates how the pattern can be used to address theproblem.Forces and context: A description of external issues (forces) that can affect how thepattern is used and also the external issues that will be resolved when the pattern isapplied.Solution: A description of how the pattern is applied to solve the problem with anemphasis on structural and behavioral issues.Consequences: Addresses what happens when the pattern is applied and whattrade-offs exist during its application.Design: Discusses how the analysis pattern can be achieved through the use ofknown design patterns.Known uses: Examples of uses within actual systems.Related patterns: On e or more analysis patterns that are related to the namedpattern because (1) it is commonly used with the named pattern; (2) it is structurallysimilar to the named pattern; (3) it is a variation of the named pattern. 21
  22. 22. Negotiating Requirements Identify the key stakeholders  These are the people who will be involved in the negotiation Determine each of the stakeholders “win conditions”  Win conditions are not always obvious Negotiate  Work toward a set of requirements that lead to “win-win” 22
  23. 23. Validating RequirementsChecking for Consistency, Omissions, Ambiguity  Is each requirement consistent with the overall objective for the system/product?  Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?  Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?  Is each requirement bounded and unambiguous?  Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?  Do any requirements conflict with other requirements? 23
  24. 24. Validating Requirements Is each requirement achievable in the technical environment that will house the system or product? Is each requirement testable, once implemented? Does the requirements model properly reflect the information, function and behavior of the system to be built. Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system. Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements? 24

×