Software engg. pressman_ch-7-complete
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Software engg. pressman_ch-7-complete

on

  • 282 views

 

Statistics

Views

Total Views
282
Views on SlideShare
282
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software engg. pressman_ch-7-complete Presentation Transcript

  • 1. Chapter 7 Requirements Engineering SWE311_Ch07 (071) Software & Software Engineering Slid e1
  • 2. Objectives  Introduce Requirements Engineering concepts  Introduce major tasks of Requirements Engineering SWE311_Ch07 (071) Software & Software Engineering Slid e2
  • 3. Overview  Requirements engineering helps software engineers better understand the problems they are trying to solve.  Building an elegant computer solution that ignores the customer's needs helps no one.  It is very important to understand the customer's wants and needs before you begin designing or building a computer-based solution.  The requirements engineering process begins with inception, moves on to elicitation, elaboration, negotiation, problem specification, and ends with review or validation of the specification.  The intent of requirements engineering is to produce a written understanding of the customer's problem.  Several different work products might be used to communicate this understanding (user scenarios, function and feature lists, analysis models, or specifications). SWE311_Ch07 (071) Software & Software Engineering Slid e3
  • 4. Requirements Engineering  Requirement: A function, constraint or other property that the system must provide to fill the needs of the system’s intended user(s) Engineering: implies that systematic and repeatable techniques should be used to ensure that system requirements are complete, consistent, relevant . . . etc.  Requirement Engineering covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a system.  RE means that requirements for a product are defined, managed and tested systematically SWE311_Ch07 (071) Slid Software & Software Engineering e4 
  • 5. Requirements Engineering  Must be adapted to the needs of a specific process, project, product, or people doing the work.  Begins during the software engineering communication activity and continues into the modeling activity.  In some cases requirements engineering may be abbreviated, but it is never abandoned.  It is essential that the software engineering team understand the requirements of a problem before the team tries to solve the problem. SWE311_Ch07 (071) Software & Software Engineering Slid e5
  • 6. Types of Requirements  Functional requirement   A requirement that specifies a function or service that a system must be capable of performing from user’s point of view. Non-functional requirement A requirement that describes the property of the system including performance, reliability, usability etc. SWE311_Ch07 (071) Slid  Software & Software Engineering e6
  • 7. What do we achieve by end of RE  Full understanding of what the stakeholders really need of the system  Complete and accurate representation of that to be communicated to system developers SWE311_Ch07 (071) Software & Software Engineering Slid e7
  • 8. Characteristics of a Good Requirement  Clear and Unambiguous     Correct   A requirement contributes to a real need Understandable   standard structure has only one possible interpretation Not more than one requirement in one sentence A reader can easily understand the meaning of the requirement Verifiable  A requirement can be tested Complete  Consistent  Traceable SWE311_Ch07 (071) Software & Software Engineering  Slid e8
  • 9. Why is Getting Good Requirements Hard?      Stakeholders don’t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the RE process. New stakeholders may emerge and the business environment change. SWE311_Ch07 (071) Software & Software Engineering Slid e9
  • 10. Requirements Engineering Tasks  Inception  Elicitation  Elaboration  Negotiation  Specification  Requirements Validation Requirements management SWE311_Ch07 (071) Software & Software Engineering  Slid e 10
  • 11. Requirements Engineering-I  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 SWE311_Ch07 (071) Software & Software Engineering Slid e 11
  • 12. Elicitation  Elicitation—elicit requirements from all stakeholders  Find out from customers what the product objectives are  what is to be done  how the product fits into business needs, and  how the product is used on a day to day basis SWE311_Ch07 (071) Software & Software Engineering Slid e 12
  • 13. Elaboration  Elaboration—create an analysis model that identifies data, function and behavioral requirements  Focuses on developing a refined technical model of software functions, features, and constraints using the information obtained during inception and elicitation SWE311_Ch07 (071) Software & Software Engineering Slid e 13
  • 14. Negotiation  Negotiation—agree on a deliverable system that is realistic for developers and customers  Requirements are categorized and organized into subsets  Relations among requirements identified  Requirements reviewed for correctness  Requirements prioritized based on customer needs SWE311_Ch07 (071) Software & Software Engineering Slid e 14
  • 15. Requirements Engineering-II  Specification—can be any one (or more) of the following:  A written document  A set of models  A formal mathematical specification  A collection of user scenarios (use-cases)  A prototype SWE311_Ch07 (071) Software & Software Engineering Slid e 15
  • 16. Requirements Validation  Requirements Validation—formal technical 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. SWE311_Ch07 (071) Software & Software Engineering Slid e 16
  • 17.  Requirements management  Set of activities that help project team to identify, control, and track requirements and changes as project proceeds  Many of these activities are identical to those that make up the software configuration management (SCM) process  Requirements are first identified, tagged with a unique identifier and classified by type (functional, data, behavioral, interface, or output)  Traceability tables (e.g., features, source, dependency, subsystem, interface) are developed and updated any time a requirement is modified)  Database systems are invaluable in helping software teams track requirement changes SWE311_Ch07 (071) Software & Software Engineering Slid e 17
  • 18. Traceability Tables  Features traceability table (shows how requirements relate to customer observable features)  Source traceability table (identifies source of each requirement)  Dependency traceability table (indicate relations among requirements)  Subsystem traceability table (requirements categorized by subsystem) Interface traceability table (shows requirement relations to internal and external interfaces) SWE311_Ch07 (071) Slid Software & Software Engineering e 18 
  • 19. Initiating Requirements Engineering Process Identify stakeholders  “who 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? SWE311_Ch07 (071) Software & Software Engineering  Slid e 19
  • 20.  The next set of questions enable developers to better understand the problem and the customer's perceptions of the solution  How would you characterize good output form a successful solution?  What problem(s) will this solution address?  Can you describe the business environment in which the solution will be used?  Will special performance constraints affect the way the solution is approached? SWE311_Ch07 (071) Software & Software Engineering Slid e 20
  • 21.  The final set of questions focuses on communication effectiveness  Are you the best person to give "official" answers to these questions?  Are my questions relevant to your problem?  Am I asking too many questions?  Can anyone else provide additional information?  Should I be asking you anything else? SWE311_Ch07 (071) Software & Software Engineering Slid e 21
  • 22. Eliciting Requirements  meetings are conducted and attended by both software engineers and customers  rules for preparation and participation are established  A flexible 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 SWE311_Ch07 (071) Software & Software Engineering Slid e 22
  • 23. Eliciting Requirements Conduct FA ST m eet ings Mak e lis t s of f unc t ions , clas s es Mak e list s of c onst 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 no y es Use QFD t o priorit iz e requirem ent s def ine act ors inf orm ally priorit ize requirem ent s draw use-cas e diagram writ e s cenario Creat e Use-cas es c om plet e t em plat e SWE311_Ch07 (071) Software & Software Engineering Slid e 23
  • 24. 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 SWE311_Ch07 (071) Software & Software Engineering Slid e 24
  • 25. User-scenarios/use-cases  describe how the system will be used  Developers and users create a set of usage threads for the system to be constructed SWE311_Ch07 (071) Software & Software Engineering Slid e 25
  • 26. 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 understand requirements. requirements SWE311_Ch07 (071) Software & Software Engineering Slid e 26
  • 27. 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? SWE311_Ch07 (071) Software & Software Engineering Slid e 27
  • 28. Use-case Drawbacks  Lack of formality in use-case descriptions  Not all systems have explicitly defined actors  Use-cases are not inherently object-oriented  Developers have a tendency to functionally decompose usecases. SWE311_Ch07 (071) Software & Software Engineering Slid e 28
  • 29. Use Case Modeling  A full use-case model comprise of:    Use Case    A diagram, describing relations between use-cases and actors. A document describing the use case in details A sequence of actions a system performs to yield an observable result of value to a particular actor Stevens/Pooley: A task which an actor needs to perform with the help of the system Actor Someone or something outside the system that interacts with the system  A user of the system in a particular role SWE311_Ch07 (071)  Actors are NOT part of the system  Software & Software Engineering Slid e 29
  • 30. Use Case Diagram Objective 1. 2. Create a semi-formal model of the functional requirements Analyze and define:    Scope External interfaces Scenarios and reactions SWE311_Ch07 (071) Software & Software Engineering Slid e 30
  • 31. What Makes Good Use-Case Specification?  Lack of ambiguity   Completeness   They should cater for all current demands of the system. Consistency   Each requirement must be interpreted in a single manner. Requirements should not conflict with each other. If there are, tradeoffs must be detected and discussed. Avoid design  Requirements should raise a need, not answer it. (Why?) SWE311_Ch07 (071) Software & Software Engineering Slid e 31
  • 32. Use Cases    Each use case has a name In the UML, a use case is represented as an oval A family (or set, or class) of scenarios    A sequence of interactions A set of different but related scenarios Documenting Use Cases  A UML Diagram showing all of them     Actors are stick-figures; use cases are ovals For each use case define using English A clear textual description A set of scenarios in outline form SWE311_Ch07 (071) Software & Software Engineering Slid e 32
  • 33. Relationships between Use Cases  UML supports two relationships between two use cases  <<includes>>    before UML 1.3 <<includes>> was <<uses>> The source use case always includes the actions specified in the target use case <<extends>>  The target use case my include the behavior of the source use case SWE311_Ch07 (071) Software & Software Engineering Slid e 33
  • 34. Documenting Use Cases  Use case name   Summary   A brief description of the use case, typically one or two sentences. Dependency   Each use case is given a name. Description of whether the use case depends on other use cases, that is, whether it includes or extends another use case. Actors  Names of the actors that participate in the use case SWE311_Ch07 (071) Software & Software Engineering Slid e 34
  • 35. Documenting Use Cases (Cont’d)  Preconditions   Description   Description of the main sequence of the use case, which is the most usual sequence of interactions between the actor and the system. Alternatives   One or more conditions that must be true at the start of the use case Description of alternative branches off the main sequence. Postcondition  Condition that is always true at the end of the use case if the main sequence has been followed. SWE311_Ch07 (071) Software & Software Engineering Slid e 35
  • 36. Preconditions • • One or more conditions that must be true at the start of the use case Examples    User account exists User has enough money in her account There is enough disk space SWE311_Ch07 (071) Software & Software Engineering Slid e 36
  • 37. Post-Conditions   Condition that is always true at the end of the use case if the main sequence has been followed. Examples    Money was transferred to the user account User is logged in The file is saved to the hard-disk SWE311_Ch07 (071) Software & Software Engineering Slid e 37
  • 38. Use-Cases – Common Mistakes     Complex diagram No system No actor Too many user interface details   “User types ID and password, clicks OK or hits Enter” Very low goal details     User provides name User provides address User provides telephone number … SWE311_Ch07 (071) Software & Software Engineering Slid e 38
  • 39. Example 1: Validate PIN Use Case  Use case name   Summary   System validates customer PIN. Actor   Validate PIN ATM Customer Precondition ATM is idle, displaying a Welcome message. SWE311_Ch07 (071) Software & Software Engineering  Slid e 39
  • 40. Example 1: Validate PIN Use Case (Cont’d)  Description 1. Customer inserts the ATM card into the Card Reader. 2. If the system recognizes the card, it reads the card number. 3. System prompts customer for PIN number 4. Customer enters PIN 5. System Checks the expiration date and whether the card is lost or stolen. 6. If card is valid, the system then checks whether the user-entered PIN matches the card PIN maintained by the system. 7. numbers match, the system checks that accounts are accessible with the ATM card. 8. System displays customer accounts and prompts customer for transaction type: Withdrawal, Query, or Transfer. SWE311_Ch07 (071) Software & Software Engineering Slid e 40
  • 41. Example 1: Validate PIN Use Case (Cont’d)  Alternatives        If the system does not recognize the card, the card is ejected. If the system determines that the card date has expired, the card is confiscated. If the system determines that the card has been reported lost or stolen, the card is confiscated. If the customer-entered PIN does not math the PIN number for this card, the system re-prompts for the PIN. If the customer enters the incorrect PIN three times, the system confiscates the card. If the customer enters Cancel, the system cancels the transaction and ejects the card. Postcondition  Customer PIN has been validated. SWE311_Ch07 (071) Software & Software Engineering Slid e 41
  • 42. Example 2: Withdraw Funds Use Case  Use case name   Summary   ATM Customer Dependency   Customer withdraws a specific amount of funds from a valid bank account. Actor   Withdraw Funds Include Validate PIN abstract use case Precondition  ATM is idle, displaying a Welcome message. SWE311_Ch07 (071) Software & Software Engineering Slid e 42
  • 43. Example 2: Withdraw Funds Use Case (Cont’d)  Description 1. Include Validate PIN abstract use case. 2. Customer selects Withdrawal, enters the amount, and selects the account number. 3. System checks whether customer has enough funds in the account and whether the daily limit will not be exceeded. 4. If all checks are successful, system authorizes dispensing of cash. 5. System dispenses the cash amount. 6. System prints a receipt showing transaction number, transaction type, amount withdrawn, and account balance. 7. System ejects card. 8. System displays Welcome Message. SWE311_Ch07 (071) Software & Software Engineering Slid e 43
  • 44. Example 2: Withdraw Funds Use Case (Cont’d)  Alternatives   If the system determines that there are insufficient funds in the customer’s account, it displays an apology and eject the card.  If the system determines that the maximum allowable daily withdrawal amount has been exceeded, it displays an apology and ejects the card.   If the system determines that the account number is invalid, it displays an error message and ejects the card. If the ATM is out of funds, the system displays an apology, ejects the card, and shuts down the ATM. Postcondition Customer funds have been withdrawn. Customer funds have SWE311_Ch07 (071) been withdrawn. Software & Software Engineering  Slid e 44
  • 45. The sections of a use case  Name. The name should implicitly express the user's intent or purpose of the use case  Identifier [Optional]. A unique identifier, such as "UC1701," that can be used in other project artifacts to refer to the use case.  Description. Several sentences summarizing the use case.  Actors [Optional]. The list of actors associated with the use case. SWE311_Ch07 (071) Software & Software Engineering Slid e 45
  • 46. The sections of a use case (cont.)  Status [Optional]. An indication of the status of the use case, typically one of: work in progress, ready for review, passed review, or failed review.  Frequency. How often this use case is invoked by the actor. Example, once per each user login or once per month.  Preconditions. A list of the conditions, if any, that must be met before a use case may be invoked. Postconditions. A list of the conditions, if any, that will be true after the use case finishes successfully. SWE311_Ch07 (071) Slid Software & Software Engineering e 46 
  • 47. The sections of a use case (cont.)  Extended use case [Optional]. The use case that this use case extends (if any).  Included use cases [Optional]. A list of the use cases this one includes.  Assumptions [Optional]. Any important assumptions about the domain that you have made when writing this use case.  Basic course of action. The main path of logic an actor follows through a use case. Often referred to as the main path because it describes how the use case works when everything works as it normally should.  Alternate courses of action. The infrequently used paths of logic in a use case, paths that are the result of an alternate way to work, an exception, or an error condition. SWE311_Ch07 (071) Software & Software Engineering Slid e 47
  • 48. The sections of a use case (cont.)  Change history [Optional]. Details about when the use case was modified, why, and by whom.  Issues [Optional]. A list of issues or action items, if any, that are related to the development of this use case.  Decisions . A list of critical decisions pertaining to the content of the use case. It is important to record these decisions to maintain a group memory. SWE311_Ch07 (071) Software & Software Engineering Slid e 48
  • 49. An Example  A complete example may be found in the following site  http://www.cs.gordon.edu/courses/cs211/ATMExample/index.htm SWE311_Ch07 (071) Software & Software Engineering Slid e 49
  • 50. Negotiating Requirements  Identify the key stakeholders   Determine each of the stakeholders “win conditions”   These are the people who will be involved in the negotiation Win conditions are not always obvious Negotiate  Work toward a set of requirements that lead to “win-win” SWE311_Ch07 (071) Software & Software Engineering Slid e 50
  • 51. Key points        It's not a competition Map out a strategy Listen actively Focus on other party's interests Don't let it get personal Be creative Be ready to commit SWE311_Ch07 (071) Software & Software Engineering Slid e 51
  • 52. Validating Requirements-I  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? SWE311_Ch07 (071) Software & Software Engineering Slid e 52
  • 53. Validating Requirements-II  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. SWE311_Ch07 (071) Software & Software Engineering Slid e 53