Requirements Engineering Unit 4: Requirements modeling, specification & prioritization

Transcription

1 Unit 4: Requirements modeling, specification & prioritization Department of Computer Science / Rijksuniversiteit Groningen (RUG) 9/29/ /29/ What we can do when stakeholders are busy Business process first, and then system and user requirements Observation method Individual meetings rather than joint workshops Meet keenest people first Corridor conversations, lunches, office dropins Talk to them about their day to day work Course outline Requirement negotiation process Requirements elicitation Requirements documentation Requirements management Requirement validation Requirement analysis 9/29/ Last Unit Requirement elicitation This Unit Requirement modeling & specification Next Unit 9/29/ Requirement specification & validation

2 9/29/ /29/ Contents RE modeling methods (use case modeling) How to write good use case How to write good requirements specification How to do requirements prioritization Requirements modeling 9/29/ /29/ Modeling is important for understanding Application domain Model domain ATM system Withdraw cash Dog: Actor Withdraw cash: Usecase ATM: System boundary Modeling purpose in RE Easy understanding and communication Checking the understanding (sequence diagram) Uncovering problems (scope, terminology) Efficient requirement management Guiding the requirement elicitation (actors from stakeholders) Measure of development progress (package based)

3 9/29/ /29/ RE modeling methods Goal-oriented Scenario-based Aspect-oriented Stakeholder-oriented Commonality and variability based Requirement reuse-driven Use case modeling B. Cheng and J. Atlee. Research directions in requirements engineering. Proceedings of the 29th International Conference on Future of Software Engineering (FOSE), pages , Use case and requirement specification User requirements Software Use cases modeling Requirements Specification trace back FR NFR Detailed requirements specification 9/29/ /29/ Use case modeling Use case modeling: overview Use Case What is use case modeling? Core concepts Diagram tour Modeling tips

4 9/29/ /29/ What is use case modeling? Use case modeling: core elements A view of a system that emphasizes the behavior as it appears to external users System functionality partition into transactions ( use cases ) that yields an observable result of value to a particular users ( actors ). Construct Use case Actor System boundary Description A sequence of actions, including variants, a system performs that yields an observable result of value to a particular actor. A set of roles that the users of use cases play when interacting with the use cases Represent the boundary between the system and the actors who interact with the system Syntax 9/29/ /29/ Use case modeling: core relationships Use case diagram tour Construct association generalization extend include Description The participation of an actor in a use case A taxonomic relationship between a general actor and a more specific actor A relationship from an extension use case to a base use case A relationship from an base use case to a inclusion use case Syntax «extend» «include» By examples use cases, actor and their relationships Use case description text or interaction diagrams (sequence or collaboration diagram)

5 9/29/ /29/ Use case diagram Use case relationships Use case Association Telephone Catalog Check status Actor Supply Customer Data Order Product Arrange Payment Place order Salesperson «include» «include» «include» System boundary Customer Fill orders Establish credit Shipping Clerk Supervisor Place Order Extension points «extend» 1 * additional requests : the salesperson asks for after creation of the order the catalog Salesperson Request Catalog back 9/29/ /29/ Actor relationships Use case description: Change Flight Salesperson 1 * Place Order Change Flight Client Account DB Traveler Supervisor 1 * Establish Credit Airline Reservation System

6 9/29/ /29/ Use case description: Change Flight Actors traveler, client account database, airline reservation system Pre-conditions: Traveler has logged on to the system and selected change flight itinerary option Post-conditions: Traveler gets flight itinerary modification result Use case description: Change Flight Basic course System retrieves traveler s account and flight itinerary from client account database System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. System asks traveler for new departure and destination information; traveler provides information. If flights are available then System displays transaction summary Alternative courses If there are no flights available 9/29/ /29/ Use case modeling tips (1) Communication purpose Observable result to actor Understandable by both domain experts and developers Naming scheme Use verbs + nouns, behavior and results Help derive objects and messages for detailed design (e.g., interaction diagrams) Use case modeling tips (2) Factor out common usages use «include»: usage required by multiple use cases use «extend»: the usage may be optional Use case diagram should the same level of abstraction include only actors required by the use case organized by packages when large number of UC

7 9/29/ /29/ How to write good use case Use Case Typical problems when using use case modeling 9/29/ /29/ Top 1 mixed-up system boundary Computer system boundary System user System? Ticket Ordering System Business user System user

8 9/29/ /29/ Business boundary Use case model layout Ticket Sales Business System Order Tickets View Schedule Kiosk Customer Create Schedule Credit Card Validation System Schedule Administrator 9/29/ /29/ Top 2 - Actor s point of view Top 2 - Actor s point of view Symptom 1 Order tickets: Use case Symptom 2 Kiosk Customer Process Tickets Order Display Schedule Kiosk Customer Order Tickets View Schedule Basic course Ticket machine gets the credit card; Ticket machine verifies the credit card information; Ticket machine gets ticket schedule info; Ticket machine processes the credit card payment; Ticket machine prints out the ticket. All about the internal functionality of ticket machine

9 Revised use case specification 9/29/ Order tickets: Use case Basic course Kiosk customer inserts the credit card into the Ticket machine; Kiosk customer gets the verification information of the the credit card by the Ticket machine; Kiosk customer selects the ticket schedule info in the Ticket machine; Kiosk customer confirms the ticket payment; Kiosk customer gets the printed out ticket from the Ticket machine. All about the interactions between actor and system Top 2 - Actor s point of view Use case model is not a data/process flow 9/29/ <<include>> and <<extend>> are not for functional or data decomposition Kiosk Customer Display Tickets <<include>> Order Tickets <<include>> Print Tickets <<include>> Deliver Tickets Symptom 3 back 9/29/ /29/ Tips Don tbe a developer, be the actor s role Don t ask how system work, but what system should provide to actor Top 3 - Unified actor name Schedule Administrator View Schedule Create Schedule Schedule Administrator Schedule Manager Edit Schedule Scheduler

10 9/29/ /29/ Glossary Top 4 - Too many use cases Actor name Schedule Administrator Meaning The role to manage the ticket schedule information in the Ticket Ordering System. Alias Schedule Manager Scheduler Pseudo user interface use case Symptom 1 Select Ticket Date Select Seat Preference Kiosk Customer Input Credit Card Info Get Ticket Ticket Ordering System 9/29/ /29/ Top 4 - Too many use cases Package them Symptom 2 Top 5 - A spider web An actor interacts with every use case Symptom 1 Ticket Ordering System Ticket Ordering System Actor A Package 1 Package 2 Package 1 Order Tickets Order Tickets Actor D Actor B Package 3 Package 4 Actor A View Schedule Phone Clerk View Schedule Actor C Actor E Package 5 Emplyee Create Schedule Schedule Administrator Create Schedule

11 9/29/ /29/ Top 5 - A spider web An use case interacts with every actor Symptom 2 Ticket Ordering System View Schedule View Schedule Top 6 - Too long use case specification & vague name Use case specification goes on for pages Coarse use case use, maintain, process, manage, etc. Too much internal processing description details Kiosk Customer Order Ticket Ticketer Order Ticket Phone Clerk View Daily Sales Report View Daily Sales Report Use Schedule Kiosk Customer Phone Clerk 9/29/ /29/ Top 7 customers don t understand/like use case Infotainment system (SA course 2008) Put short explanation (1-2 page) of use cases with a simple example (better from the domain which customers are familiar with) Adding a context section in use case specification template Organize the use case packages by customer s advice Avoid using <<include>> and <<extend>> relationships Use SRS in natural language if user don t like use case Use case for the analysis and semi-finished product

12 9/29/ /29/ How to write good specification SRS Requirements specification 9/29/ /29/ A good requirement specification Complete Traceable Testable Consistent Uniquely identified Design free Using right auxiliary verbs Shall Must be implemented Should, may Can be implemented Will Future requirements

13 9/29/ /29/ Example 1 Examples: refining requirements specification Software will not be loaded from unknown sources onto the system without having the software tested and approved. Problem Two constraints are specified simultaneously Unclear about the relationship between them No unique identifier 9/29/ /29/ Example 1: Re-specification Software shall be loaded onto the operational system only after it has been tested and approved. Example The system shall prevent the processing of duplicate electronic files by checking a SDATE record. An message shall be sent. Problem Two shall under one requirement identifier What s the content of message? For what purpose? What is SDATE?

14 9/29/ /29/ Example 2: Re-specification The system shall: a. Prevent processing of duplicate electronic files by checking the date and time of the submission. b. Send the following message: b.1 Request updated submission of date and time, if necessary, or b.2. That the processing was successful, if successful. Example The system shall process two new fields information at the end of state record. Problem What are the two new fields information? Can not be implemented and tested 9/29/ /29/ Example 3: Re-specification The system shall provide the following data items at the end of state record: a. Submission date and time. b. production count to that date in total. Example All sensitive computer-resident information shall have system access controls to ensure that it is not improperly disclosed, modified, deleted, or rendered unavailable. Problem What is sensitive information?

15 9/29/ /29/ Example 4: Re-specification All sensitive computer-resident (Reference Sensitive Information Table and Levels of Protection for Sensitive Information Table ) Example The system shall have no single point failures. Problem Unclear application scope of this requirement 9/29/ /29/ Example 5: Re-specification The following system components shall have no single point failure: a. Host servers. c. Network routers. d. Access servers. e. Hubs. f. Switches. Example The system shall receive and process state data from the State Processing Subsystem. Problem Vague words process, state data

16 9/29/ /29/ Example 6: Re-specification The system shall receive: a. Production data that contain data from multiple states. b. Financial state data for one or more states, extracted by the State Processing Subsystem The system shall parse multi-state data to respective state files. Example The enrollment process shall take 1 to 10 calendar days to complete for all enrollment types. (STH: system administrator) The enrollment process shall take no more than 3 days to complete for Credit enrollment (STH: financial administrator) Problem Inconsistent requirements 9/29/ /29/ Example 8: Re-specification The enrollment process shall take: a. 1 to 3 calendar days to complete for Credit enrollment. b. 1 to 10 calendar days to complete for all other enrollment types. Example When doing calculations, the software shall produce correct results. Problem This is not a requirement Something obvious Remove it

17 9/29/ /29/ Specification checkpoints Vague words? Info, fields, Process, maintenance, Good functions, well documented, clear specified, Correct result, shall run Specific terms? SDATE, CODE131, Obvious and redundant requirements Define shall not requirements System boundary What the system shall do What the system shall not do? 9/29/ /29/ Examples of shall not requirements The system shall not allow users to modify access permissions on any files that they have not created. (security) The system shall not allow the simultaneous activation of more than three alarm signals. (safety) Define shall not requirements Think about them in a positive way What the system shall do What shall the system do to achieve X?

18 9/29/ /29/ Revision of shall not requirements The system shall not all users to modify access permissions on any files that they have not created. (security) The system shall allow access permissions modification only to the creators of the files (to protect files). The system shall not allow the simultaneous activation of more than three alarm signals. (safety) The system shall allow the simultaneous activation of at most three alarm signals (to reduce noise). Requirements prioritization 9/29/ /29/ Requirements prioritization Time and resource limitations RE goal is to add business value Dilemma of project manager How to select a subset of requirements How to produce a subset of system that still meets customers needs

19 9/29/ /29/ Pairwise and cost-value comparison approach Simple Reasonable Repeatable Verifiable Tool support Industrial proven Cost-value of requirements Estimated cost of the implementation of a requirement Value to customers and users of a requirement 9/29/ /29/ Why pairwise? Results of method Traditional method calculate the cost by money spent slow, vague, and various in many factors Prioritization based on relative value rather than absolute assignments Fast, accurate, and trustworthy B A A You can easily tell A is taller than B, but it is difficult to tell what A s height is.

20 9/29/ /29/ Steps of method Pairwise comparison (value and cost) Requirements engineers review the candidate requirements for completeness All (selective) stakeholders make pairwise comparison of all requirements Requirements engineers make estimation of the relative cost Requirements engineers normalize the requirement's relative value and cost, and plot these on a cost-value diagram reciprocals Req1/Req2 9/29/ /29/ Results normalization Value_Req2= 1.98/4 = 0.5 Results in percent Value_Req13=

21 9/29/ /29/ Plot the results Value_Req13=0.21 Cost_Req13 = 0.23 Known issues Consistency Value_Req1 > Value_Req2; Value_Req2 > Value_Req3; Value_Req3 > Value_Req1; Consistency index calculation Interdependency of requirements Req1 Req2 Req3 e.g., a high-cost and low-value requirement should be implemented first Number of pairwise comparison is O(n 2 ) Tool support (calculation, rationale documentation) J. Karlsson and K. Ryan. A cost-value approach for prioritizing requirements. IEEE Software, /29/ /29/ Review of today How to write good use cases Top problems in writing good specifications Cost-value approach for prioritizing requirements Reading - L. Probasco and D. Leffingwell. Combining software requirements specifications with use-case modeling. Rational Software, IEEE. IEEE Recommended Practice for Software Requirements Specifications. IEEE Standard Committee, IEEE Std , J. Karlsson and K. Ryan. A cost-value approach for prioritizing requirements. IEEE Software, 14(5):67-74, 1997.

22 9/29/ Course assignment - (1) course project meeting submissions, see deadlines Submission method (1) should be submitted in the meeting agenda and minutes (requirements modelling, specification, and prioritization) of Week 40