4 - Requirements Engineering v1

4 - Requirements Engineering v1 - Requirements Engineering...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Requirements Engineering Unified Process: Phases, Iterations, and Workflows Requirements Inception Elaboration Construction Transition amount of work Analysis Design Implementation Test Preliminary Iterations I1 I2 In In+1 In+2 Im Im+1 2 Workflows of an Iteration Requirements – capturing what the system should do Analysis – refining and structuring the requirements Design – realizing the requirements in system architecture Implementation – building the software Test – Verifying that the implementation works as desired 3 The Importance of Requirements Project Failures Incomplete requirements Lack of user involvement Lack of resources Unrealistic expectations Lack of executive support Changing requirements Lack of planning Incomplete requirements are the primary reason that projects fail! Didn't need it any longer 4 Requirements Engineering Requirements elicitation o o o o o o o o It is the “requirements” workflow Results in a requirements statement Mainly communicate with clients & users Natural language It is the “analysis” workflow Results in analysis models Mainly communicate among developers Formal and semiformal notation (e.g., UML 2) 5 Requirements analysis Requirements Engineering Models Organize artifacts of requirements engineering Input to the software design process Consist of o Requirements model comprising functional and non-functional requirement statements o Analysis model comprising use case model and domain model 6 Requirements Engineering Models (cont.) Functional requirements Requirements model Requirements Engineering Models Analysis model Domain Model Non-functional requirements Use case model 7 Required Properties of Requirements Completeness o All possible scenarios through the system are described, including exceptional behavior by the user or the system. Consistency o There are functional or nonfunctional requirements that contradict each other Clarity o There are no ambiguities in the requirements. Correctness o The requirements represent the client’s view. Realistic o Requirements can be implemented and delivered Verifiable o Repeatable test can be designed to demonstrate the system fulfills the requirements specification Traceable o Each system function can be traced to a corresponding set of functional requirements 8 Types of Requirements Elicitation Greenfield engineering o Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client o Triggered by user needs Re-engineering o Re-design and/or re-implementation of an existing system using newer technology o Triggered by technology enabler Interface engineering o Provide the services of an existing system in a new environment o Triggered by technology enabler or new market needs 9 Approaches to Capture Requirements Two approaches o The use case approach o The feature list approach Use cases are derived from goal-oriented context A feature list o Does not relate to the requirements in a cohesive context o Duplicates the purposes of use cases o Can be desirable when use cases are not natural fit for the application 10 Activities of Requirements Engineering 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Define vision and goals Build business process model Generate requirements statement Construct domain model Define boundary and identify actors Identify goals for each primary actor Find use cases Construct textual use cases Create requirements traceability matrix Construct use case diagram Construct use case interaction overview diagram Construct use case sequential diagrams 11 Activity 1 – Define Vision an Goals Vision o Defines the stakeholders’ view of the product with needs and features o Contains an outline of the core requirements Elaborate business goals via measurable organizational value (MOV) 12 Steps to Develop Measurable Organizational Value 1. 2. 3. 4. 5. Identify the desired area of impact Identify the desired value of the IT project Develop an appropriate metric Set a time frame for achieving the MOV Verify and get agreement from the project stakeholders 6. Summarize the MOV in a clear and concise table 13 A MOV Table Organizational Impact Strategic Value Metric Time Frame • Increase reliability and the brand image of Pilot Angels • Reduce the scheduling time for each customer. • Provide better schedule and less stopovers • Provide matching volunteers • Reduce turn downs due to nonavailability of pilots from 35% to 20% • Reduce schedule changes from 40% to 20% • Reduce ‘time to fly’ by 6 hours. • Reduce no of stopovers per 1000 flight mile from 5 to 3. • Reduce the average wait time between flights from 2 hours to ½ an hour. • Increase availability of matching volunteers from 40% to 60% • Reduce personnel & communication cost of scheduling by 73%. • Reduce total cost of scheduling by 59% • Reduce scheduling time from 8 hours to 2 hours. • Increase the accuracy of contribution recognition program to 95% • Increase the number of patients served from 100 to 150 • 24 months • 12 months • 12 months • 12 months • 12 months • 12 months Customer Financial • Reduce personnel and communication cost of scheduling. • Reduce total cost of scheduling • Reduce the scheduling cycle time. • Recognize specific pilots for their contribution. • Increase the number of patients served. • 12 months • 60 months Operational • 12 months • 24 months • 24 months Social 14 Activity 2 – Build Business Process Model Identify the business events by discovering the interfaces to external entities or processes Find the business activities must take for each event Combine related activities into a single process Use UML 2 activity diagram to create a business process diagram o Use action nodes to show processes that contain activities o Use an object nodes to show the interaction between two processes o Use object nodes to show the interactions between processes and external entities or processes o Do not use control nodes Decompose a business process diagrams into subprocess diagrams iteratively until all processes become use cases 15 A Business Process Diagram Contact Information Request for Quotation Quotation Product/Service Information Lead [Raw] Manage Lead Opportunity [Raw] Manage Opportunity Contract [Raw] Lead Management Rules Opportunity Management Rules Rule Setting Criteria Manage Rule Contract Management Rules Manage Contract Contract [Final] Contract Concerns 16 A Business Subprocess Diagram Lead [Raw] Import Lead Lead [Imported] Assign Lead Lead Assignment Rules Lead [Assigned] Contact Information Lead Qualification Rules Qualify Lead Lead [Unique] Merge Lead Lead Merging Rules Opportunity [Raw] 17 Business process diagram Contact Information Request for Quotation Quotation Product/Service Information Lead [Raw] Process Lead Opportunity [Raw] Process Opportunity Contract [Raw] Lead Management Rules Opportunity Management Rules Rule Setting Criteria Manage Rule Contract Management Rules Process Contract Contract [Final] Contract Concerns 18 Business subprocess diagram Additional Contract Information Contract [Raw] Import Contract Contract [Imported] Prepare Contract Contract Rules Contract [Draft] Contract [Denied] Finalize Contract Contract [Approved] Approve Contract Approval Rules Contract [Final] Opportunity [Raw] 19 Activity 3 – Generate Requirements Statement Functional requirements o What the system should do o The interactions between the system and its environment independent from implementation o Modeled by use cases Nonfunctional requirements o How the functional requirements should be implemented o Two categories o Quality of service o Constraints 20 Requirement Format <id> The <system> shall <function> unique identifier name of system keyword function to be performed For example, “R2.2.6.1 The ATM system shall validate PIN and password." There is no UML standard way of writing requirements. The above uniform sentence structure is recommended. 21 Requirements Examples Functional requirements o The Sales Management System shall merger redundant leads o The Sales Management System shall present rules to the sales executive for qualifying a lead to an opportunity o The Sales Management System shall acquire approval from a contract manager to finalize a contract Non-functional requirements o The Sales Management System shall be written in Java o The Sales Management System shall communicate with the credit system by using 256-bit encryption o The Sales Management System shall retrieve a customer account information in three seconds or less 22 Organize Requirements R1 Functional requirements R1.1 Manage Lead R1.2 Manage Opportunity R1.3 Manage Contract R1.4 Manage Rule R2 Non-functional requirements R2.1 Quality of Service R2.1.1 Performance R2.1.2 Capacity R2.1.3 Usability R2.1.4 Reliability R2.1.5 Availability R2.1.6 Supportability R2.2 Constraints R2.2.1 Implementation R2.2.2 Interface R2.2.3 Operations R2.2.4 Packaging R2.2.5 Compliance to standards R2.2.6 Security R2.2.7 Legal 23 Activity 4 – Construct Domain Model Based on the project scope of the application context, select a subset of business conceptual classes as domain classes Construct a domain class diagram with domain classes, attributes, and associations with adornments Two formats to present a domain class diagram o A diagram of domain classes with attributes and associations o A diagram of domain classes with names and associations, as well as a separate table with class names and attributes 24 Domain Class Diagram – Format 1 Domain Class Diagram 25 Domain Class Diagram – Format 2 26 Domain Class Diagram – Format 2 (cont.) Administrator • Name • LoginID • Password Approval Authority • ID • Name • Person ID • Password • LoginID Assignment Rule: • Rule Value • Rule Operator • Rule Parameter Contact • Name • Title • Department • Affiliation • Address • Email • Mobile • Phone • Lead Source Contract • Status • Owner Expiration Notice • Description • Shipping Address • Company Signed Date • Customer Signed Date • Contract Term • Contract Start Date • Special Terms • Billing Address • Contract Number Lead • Company • Phone • Fax • Email • Address • Status • Mobile • Name Opportunity • Description • Status • Stage • Next Step • Close Date • Probability • Lead Source • Type • Opportunity Name Position • Title • Description • ID • Login ID • Territory ID • Location Product • Product Description • Product Name • Product Id Product Details • Date Of Check • Quantity Available • Product Quantity • Price Qualification Rule: • Rule Value • Rule Operator • Rule Parameter Quote • Date Of Quotation • Amount Sales Manager • Name • Login Id • Password • Sales Person ID Sales Representative • Password • Login ID • Sales Person ID • Name Structure • Hierarchy • Amount • Levels • Description • ID • Login ID • Territory ID • Location Territory • ID • Name • Description 27 Activity 5 – Define Boundary and Identify Actors Define the boundary of the system under development from initial domain models Actors represent external entities that interact with the system under development Actors are role abstractions 28 Boundary and Actors of the Membership System Membership System use case diagram Membership System communication relationship subject name system boundary Employee Customer actor Credit System 29 Actor Types Primary actor o Drives the use case o Uses the services of the system o Can be “clock” if the system does something in response to a time event Secondary actor o Provides a service to the system o Clarifies external interfaces and protocols o Also called “supporting actor” 30 Activity 6 – Identify Goals for Each Primary Actor Goal Levels o Enterprise goal o For example, prevent theft o Actor goal o For example, apply for membership o Subfunction goal o For example, identify myself and be validated The focus is on actor goals. 31 Activity 7 – Find Use Cases A scenario is an instance of a use case; a use case is an abstraction of a set of related scenarios A use case utterly comprehensible by the user o Use cases model a system from the users’ point of view (functional requirements) o Define possible event flow through the system o Description of interaction between objects Use cases can be found by selecting either a narrow vertical slice of the system (i.e. one scenario) or a horizontal slice (i.e. many scenarios) to define the scope of the system Use cases can also be found through prototype mock-ups Use cases are derived from actor goals Name the use case similar to the actor goal Name use cases starting with a verb 32 Benefits of Use Cases Use cases are great tools to manage a project. Use cases can form basis for whole development process o o o o o User manual System design and object design Implementation Test specification Client acceptance test Use cases provide an excellent basis for incremental & iterative development 33 Elementary Business Process (EBP) Is a term from Business Process Engineering field Can be adopted to test the validity of a base use case Business Process Engineering (Software Requirements Engineering) [Business Process Engineering] A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state. [Software Requirements Engineering] A task performed by the system within a limited time, in response to a request of a primary actor, which satisfies an actor goal and leaves the data in a consistent state. 34 Activity 8 – Construct Textual Use Cases A textual description for each use case to satisfy specific goals of a primary actor Use fully-dressed 10-section format Base type must be multi-column with a system column and at least one actor column. Extension type can be a single system column without actor columns 35 Sections of a Fully-Dressed Use Case Use case identification 2. Name 3. Type (base and/or extension) 4. Actors (primary and secondary) 5. Description (for actors and/or system) 6. Preconditions (use cases that incur this one) 7. Postconditions (for actors and/or system) 8. Main flow (must be “multi-column”) 9. Alternative flows (for not normal situations) 10. Special requirements (non-functional, optional) 1. 36 ID: UC 01 Name: Apply for Membership Type: Base Actors: • Customer - Primary Actor Description: • Customer: wants to apply for membership Preconditions: None Postconditions: • Customer is notified whether the membership is approved or not • System keeps membership on file Main flow: Customer: System: 1. Provides applicant information 2. Verifies information 3. Calculate membership fee 4. Provided two payment options – personal check and credit card 5. Selects payment type 6. Check [payment type] 6.1 If [Check] Send Customer information to UC 02 ( Pay Fee by Personal Check) 6.2 Else Send Customer information to UC 03 (Pay Fee by Credit Card) 7. Completes membership profile 8. Confirms membership profile 9. Sends member profile to UC 07 (Print Membership Card) 10. Notifies Customer about application status Alternative flows: *a. System fails 1. Goes to UC 09 (Restart System) 2. Notifies Customer. 3. Goes to UC 10 (Maintain System) 2a. System finds errors in Customer information: 1. Notifies Customer. 2. Goes to Main 1. Special Requirements: R. – Ensure confidentiality of customer information A Textual Use Case 37 ID: UC 03 Name: Pay Fee by Credit Card Type: Reference Actors: •Credit System - Supporting Actor Description: • Customer: wants to pay with credit card for membership • Credit Bank: processes request based on the validity of the given information Preconditions: UC 01 (Apply for Membership) Postconditions: • Send message to UC 01 on the status of credit card payment approval • Credit Bank process transaction if credit card payment is approved Main flow: System: Credit Bank: 1. Verifies information 2. Provided Customer information and amount to Credit Bank 3. Verifies credit and approves amount 4. Sends message to UC01 to notify Customer. 5. Signals Credit Bank to process the request. Alternative flows: *a. System fails 1. Goes to UC 09 (Restart System) 2. Notifies Credit Bank to void the transaction. 3. Sends message to UC01 to notify Customer. 4. Goes to UC 10 (Maintain System) *b. Transaction fails 1. Notifies Credit Bank to void the transaction. 2. Goes to Main 1. 1a. System finds errors in Customer information: 1. Sends message to UC01 to notify Customer. 2. Goes to Main 1. 3a. Credit Bank denies Customer credit 1. Notifies System 2. Sends message to UC01 to notify Customer Special Requirements: R – Ensure transaction integrity R. – Ensure confidentiality of customer information A Textual Use Case 38 Activity 9 – Create Requirements Traceability Matrix A RTM shows the relationship between use cases and functional requirements, A RTM shows use cases to be added for each iteration. A functional requirement has to be covered by at least one use case. A use case has to realize at least one functional requirement. All use cases must be included in the use case diagram. Each use case has a scope indicator. A scope indicator reflects the inclusion of artifacts of a use case in the project report. For example, if the scope indicator of a use case is 3, then the artifacts of this use case is covered in Chapters 1 through 3. 39 A Requirements Traceability Matrix Use Case Requirement R1.1.1 R1.1.2 R1.1.3 R1.1.4 R1.2.1 R1.2.2 R1.2.3 R1.3.1 R1.3.2 R1.4.1 R1.5.1 R1.5.2 R1.5.3 Iteration Workflows 1 RADIT 1 RADIT X X X 4 RA 3 RA 1 RADIT 1 RADIT 2 RA 2 RA 40 X X X X X X X X X UC1 X X X X X X X X UC2 UC3 UC4 UC5 UC6 UC7 UC8 Activity 10 – Construct Use Case Diagram Use cases are text documents Use case diagrams and use case relationships are secondary in use case work A use case diagram makes a good context diagram for a system or subsystem Draw a simple use case diagram in conjunction with an actor-goal list 41 A Use Case Diagram ATM System use case diagram ATM System communication relationship Deposit Check Withdraw Cash Query Account Transfer Fund Generate Report subject name system boundary Bank Clerk Set Cash Reserve use case Service Person Customer actor 42 Relationships among Use Cases Generalization o An abstract use case has different specializations o The generalization association among use cases factors out common behavior o The child use cases inherit the behavior and meaning of the parent use case and add or override some behavior <<include>> o Represent behavior that is factored out of the use case for reuse, not because it is an exception. o The base case cannot exist alone. It is always called with the extension use case <<extend>> o A use case is an option to another use case o Represent behavior that is optional or exceptional to the base use case 43 Use Case Generalization Example Sales System Find Product Customer Find Book Find CD 44 Actor Generalization Example Sales System Sales System Customer List Products Purchaser List Products Order Products Order Products Accept Payment Accept Payment Customer Sales Agent Sales Agent Calculate Commission Calculate Commission 45 <<include>> Example ID: UC 01 Name: Change Employee Details Type: Base Actors: Manager - Primary Description: Manager changes the employee details Preconditions: UC 21 (Manager is logged on to the system) Postconditions: Employee details have been changed Main flow: ID: UC 04 Name: Find Employee Details Type: Extension Actors: Description: System finds employee details Preconditions: UC 01 (Change Employee Details) Postconditions: System has found employee details Main flow: Manager: 1. Enter employee’s ID 4. Enter changes ... Alternative flows: None System: 2. <<include>> UC 04 3. Displays the details 5. Change details System: 1. Finds employee details Alternative flows: None 46 <<include>> Example (cont.) Personnel System base use case UC 01 Change Employee Details «include» UC 02 View Employee Details «include» UC 04 Find Employee Details Manager UC 03 Delete Employee Details «include» extension use case include relationship 47 <<extend>> Example ID: UC 09 Name: ReturnBook Type: Base Actors: Librarian - Primary Description: Librarian returns a borrowed book Preconditions: UC 07 (Librarian is logged on to the system) Postconditions: Book has been returned Main flow: Librarian: 1. Enters borrower's ID number. 3. Finds the book to be returned in the list of books. 4. Returns the book. 2. Displays borrower’s details including the list of borrowed books. System: 5.1 If first offence <<extend>> UC 10 5.2 else <<extebd>> UC 11 ... Alternative flows: None. 48 <<extend>> Example (cont.) UC 09 Return Book «extend» «extend» condition: {first offence} condition: {!first offence} UC 10 Issue Warning UC 11 Issue Fine 49 <<include>> and <<extend>> Example Passenger Purchase MultiCard Purchase Single Ticket <<include>> Collect Money <<extend>> <<include>> <<extend>> No Change Cancel 50 Activity 11 – Construct Use Case Interaction Overview Diagram Is a special form of activity diagram Models high level flow of control between use case interactions Represents each use case by a sequence diagram reference Expresses branching, concurrency, and iteration. Emphasizes the preconditions of each use case 51 A Use Case Interaction Overview Diagram SD REF SD REF SD REF CRUD Territory CRUD Position CRUD Structure SD REF SD REF Import Lead Define Assignment Rules SD REF Draft Contract SD REF Merge Lead SD REF Finalize Contract SD REF SD REF Import Opportunity Assign Lead SD REF [not finalize] SD REF Merge Opportunity Qualify Lead SD REF [finalize] SD REF Qualify Opportunity Convert Lead SD REF SD REF Approve Contract [not approved] [approved] SD REF Convert Opportunity Convert Contract 52 Activity 12 – Construct Use Case Sequence Diagrams Each diagram is derived from the flow of significant messages of a use case Each diagram can have three types of analysis objects: boundary, control, and entity objects Each primary or secondary actor corresponds to a boundary object. Each diagram consists of a control object that coordinates the message flow of the use case. Entity objects are domain objects. In a base use case sequence diagram o The first column corresponds to the primary actor. o The second column corresponds to a boundary object. o The third 3rd column corresponds to the control object 53 A Use Case Sequence Diagram 54 References J. Arlow and I. Neustadt, UML 2 and the Unified Process, 2nd edition, Addison Wesley, 2005. M. Blaha and J. Rumbaugh, Object-Oriented Modeling and Design with UML, 2nd edition, Prentice Hall, 2005. J. Marchewka, Information Technology Project Management, 2nd edition, Wiley, 2006. 55 ...
View Full Document

This note was uploaded on 03/03/2010 for the course CMPE 133 taught by Professor Fayad,m during the Spring '08 term at San Jose State University .

Ask a homework question - tutors are online