Requirements analysis Requirements analysis and specificationand specification

CSE432CSE432

Object-Oriented Object-Oriented Software EngineeringSoftware Engineering

Requirements analysis and Requirements analysis and system specificationsystem specification

Why is it one of first activities in software life cycle?Why is it one of first activities in software life cycle? Need to understand what customer wants first!Need to understand what customer wants first! Goal is to understand the customer’s problemGoal is to understand the customer’s problem Though customer may not fully understand it!Though customer may not fully understand it!

Requirements analysis says: “Make a list of the Requirements analysis says: “Make a list of the guidelines we will use to know when the job is done guidelines we will use to know when the job is done and the customer is satisfied.” and the customer is satisfied.” AKA AKA requirements gathering requirements gathering or or requirements engineeringrequirements engineering

System specification says: “Here’s a description of System specification says: “Here’s a description of whatwhat the program will do (not the program will do (not howhow) to satisfy the ) to satisfy the requirements.” requirements.” Distinguish requirements gathering & system analysis?Distinguish requirements gathering & system analysis? A top-level exploration into the problem and discovery A top-level exploration into the problem and discovery

of whether it can be done and how long it will takeof whether it can be done and how long it will take

Evolutionary requirementsEvolutionary requirements

RequirementsRequirements are capabilities and conditions to are capabilities and conditions to which the system and the project must conformwhich the system and the project must conform

A prime challenge of requirements analysis is to A prime challenge of requirements analysis is to find, communicate, and remember find, communicate, and remember whatwhat is really is really neededneeded, in the form that , in the form that clearlyclearly speaks to the speaks to the client and development team members. client and development team members.

Functional (Functional (whatwhat behaviors it does) behaviors it does) and non-functional (and non-functional (howhow it does them it does them))

FunctionalFunctional requirements describe system behaviors requirements describe system behaviors Priority: Priority: rank order the features wanted in importancerank order the features wanted in importance CriticalityCriticality: how essential is each requirement to the : how essential is each requirement to the

overall system?overall system? RisksRisks: when might a requirement not be satisfied? : when might a requirement not be satisfied?

What can be done to reduce this risk?What can be done to reduce this risk?Non-functionalNon-functional requirements describe other desired requirements describe other desired attributes of overall system—attributes of overall system— Product costProduct cost (how do measure cost?) (how do measure cost?) PerformancePerformance (efficiency, response time? startup time?) (efficiency, response time? startup time?) PortabilityPortability (target platforms?), binary or byte-code (target platforms?), binary or byte-code

compatibility?compatibility? AvailabilityAvailability (how much down time is acceptable?) (how much down time is acceptable?) SecuritySecurity (can it prevent intrusion?) (can it prevent intrusion?) SafetySafety (can it avoid damage to people or environment?) (can it avoid damage to people or environment?) Maintainability Maintainability (in OO context: extensibility, reusability)(in OO context: extensibility, reusability)

""Editor with undoEditor with undo" " A very simple, initial requirements specA very simple, initial requirements spec Why might a small and concise initial spec be a good idea?Why might a small and concise initial spec be a good idea? Fosters initial buy-in and agreement by everyone on teamFosters initial buy-in and agreement by everyone on team Traditional Traditional real-world specsreal-world specs are usually much longer are usually much longer

What’s the purpose of a What’s the purpose of a purposepurpose or or visionvision statement? statement?Why is Why is scopescope important? important?Why a Why a glossaryglossary of of termsterms and and definitionsdefinitions??Business case and user perspective:Business case and user perspective: Business context and case: Who wants it and why?Business context and case: Who wants it and why? User characteristics: profile of user community, expected User characteristics: profile of user community, expected

expertise with system & domainexpertise with system & domain User objectives: “wish list” from user’s perspectiveUser objectives: “wish list” from user’s perspective Interface requirements: GUI, API, communication interfaces, Interface requirements: GUI, API, communication interfaces,

software interfacessoftware interfaces

FURPS+ modelFURPS+ model(Grady 1992)(Grady 1992)

FURPS is a checklist for requirements:FURPS is a checklist for requirements:

Functional (features, capabilities, security)Functional (features, capabilities, security)

Usability (human factors, help, documentation)Usability (human factors, help, documentation)

Reliability (frequency of failure, recoverability, Reliability (frequency of failure, recoverability, predictability)predictability)

Performance (response time, throughput, Performance (response time, throughput, accuracy, availability, resource usage)accuracy, availability, resource usage)

Supportability (adaptability, maintainability, Supportability (adaptability, maintainability, internationalization, configurability)internationalization, configurability)

What’s with the + in FURPS+?What’s with the + in FURPS+?

And don’t forget….And don’t forget….Implementation (resource limitation, language Implementation (resource limitation, language and tools, hardware)and tools, hardware)Interface (constraints posed by interfacing with Interface (constraints posed by interfacing with external systems)external systems)Operations (system management in its Operations (system management in its operational setting)operational setting)Packaging (for example, a physical box)Packaging (for example, a physical box)Legal (licensing) Legal (licensing)

Desiderata for Desiderata for a requirements specificationa requirements specification

Should say Should say whatwhat, not , not how.how. Why?Why?Correct: does what the client wants, according to specification Correct: does what the client wants, according to specification Like motherhood and apple pie—how to accomplish it?Like motherhood and apple pie—how to accomplish it? Ask the client: keep a list of questions for the clientAsk the client: keep a list of questions for the client Prototyping: explore risky aspects of the system with clientPrototyping: explore risky aspects of the system with client

Verifiable: can determine whether requirements have been metVerifiable: can determine whether requirements have been met But how do verify a requirement like “user-friendly” or But how do verify a requirement like “user-friendly” or

“it should never crash”?“it should never crash”?Unambiguous: every requirement has only one interpretationUnambiguous: every requirement has only one interpretationConsistent: no internal conflictsConsistent: no internal conflicts If you call an input "Start and Stop" in one place, don't call it If you call an input "Start and Stop" in one place, don't call it

"Start/Stop" in another"Start/Stop" in anotherComplete: has everything designers need to create the softwareComplete: has everything designers need to create the softwareUnderstandable: stakeholders understand enough to buy into itUnderstandable: stakeholders understand enough to buy into it Tension between understandability and other desiderata?Tension between understandability and other desiderata?

Modifiable: requirements change!Modifiable: requirements change! Changes should be noted and agreed upon, in the spec!Changes should be noted and agreed upon, in the spec!

Use casesUse casesFirst developed by Ivar Jacobson First developed by Ivar Jacobson Now part of the UML (though not necessarily object-oriented)Now part of the UML (though not necessarily object-oriented) Emphasizes user’s point of viewEmphasizes user’s point of view Explains everything in the user’s languageExplains everything in the user’s language

A "use A "use casecase" is a set of cases or scenarios for using " is a set of cases or scenarios for using a system, tied together by a common user goala system, tied together by a common user goal Essentially descriptive answers to questions that start with Essentially descriptive answers to questions that start with

“What does the system do if …” “What does the system do if …” E.g., “What does the auto-teller do if a customer has just E.g., “What does the auto-teller do if a customer has just

deposited a check within 24 hours and there’s not enough in the deposited a check within 24 hours and there’s not enough in the account without the check to provide the desired withdrawal?”account without the check to provide the desired withdrawal?”

Use case describes what the auto-teller does in that situationUse case describes what the auto-teller does in that situation

Use case modelUse case model = = the set of all use casesthe set of all use casesWhy are use cases good for brainstorming requirements?Why are use cases good for brainstorming requirements?

Brief Use Case formatBrief Use Case format

Brief formatBrief format narrates a story or scenario of use in narrates a story or scenario of use in prose form, e.g.:prose form, e.g.:

Rent VideosRent Videos. A Customer arrives with videos to rent. . A Customer arrives with videos to rent. The Clerk enters their ID, and each video ID. The The Clerk enters their ID, and each video ID. The System outputs information on each. The Clerk System outputs information on each. The Clerk requests the rental report. The System outputs it, requests the rental report. The System outputs it, which is given to the Customer with their videos.which is given to the Customer with their videos.

Fully dressed Use Case Fully dressed Use Case (from Fowler & Scott, (from Fowler & Scott, UML DistilledUML Distilled)) Use Case: Buy a Product Use Case: Buy a Product (Describe user’s goal in user’s language)(Describe user’s goal in user’s language)Actors: Customer, System (Why is it a good idea to define actors?)Actors: Customer, System (Why is it a good idea to define actors?)1.1. Customer browsers through catalog and selects items to buyCustomer browsers through catalog and selects items to buy2.2. Customer goes to check outCustomer goes to check out3.3. Customer fills in shipping information (address; next-day or 3-day Customer fills in shipping information (address; next-day or 3-day

delivery)delivery)4.4. System presents full pricing information, including shippingSystem presents full pricing information, including shipping5.5. Customer fills in credit card informationCustomer fills in credit card information6.6. System authorizes purchaseSystem authorizes purchase7.7. System confirms sale immediatelySystem confirms sale immediately8.8. System sends confirming email to customer System sends confirming email to customer (Did we get the main scenario right?)(Did we get the main scenario right?)Alternative: Alternative: Authorization FailureAuthorization Failure (At what step might this happen?) (At what step might this happen?)6a.6a. At step 6, system fails to authorize credit purchaseAt step 6, system fails to authorize credit purchase

Allow customer to re-enter credit card information and re-tryAllow customer to re-enter credit card information and re-tryAlternative:Alternative: Regular customerRegular customer (At what step might this happen?) (At what step might this happen?)3a. System displays current shipping information, pricing information,3a. System displays current shipping information, pricing information,

and last four digits of credit card informationand last four digits of credit card information3b. Customer may accept or override these defaults3b. Customer may accept or override these defaults

Return to primary scenario at step 6Return to primary scenario at step 6

Scenario, use case and goalScenario, use case and goal

A A scenarioscenario is a specific sequence of actions is a specific sequence of actions and interactions in a use case.and interactions in a use case. One path through the use caseOne path through the use case E.g., The scenario of buying a productE.g., The scenario of buying a product

A A use caseuse case is a collection of success is a collection of success and failure scenarios describing an actor and failure scenarios describing an actor using a system to support a goal.using a system to support a goal.

Heuristics for writing use case text Heuristics for writing use case text

Avoid implementation specific language in use cases, such as Avoid implementation specific language in use cases, such as IF-THEN-ELSE or GUI elements or specific people or deptsIF-THEN-ELSE or GUI elements or specific people or depts

Which is better: “The clerk pushes the OK button.” Which is better: “The clerk pushes the OK button.” or: “The clerk signifies the transaction is done.”? or: “The clerk signifies the transaction is done.”?

The latter defers a UI consideration until design.The latter defers a UI consideration until design.Write use cases with the user’s vocabulary, the way a users Write use cases with the user’s vocabulary, the way a users would describe performing the taskwould describe performing the taskUse cases never initiate actions; actors do. Use cases never initiate actions; actors do.

Actors can be people, computer systems or any external entity Actors can be people, computer systems or any external entity that initiate an action. that initiate an action.

Use case interaction produces something of value to an actorUse case interaction produces something of value to an actorCreate use cases & requirements incrementally and iterativelyCreate use cases & requirements incrementally and iteratively

Start with an outline or high-level descriptionStart with an outline or high-level description Work from a vision and scope statementWork from a vision and scope statement Then broaden and deepen, then narrow and pruneThen broaden and deepen, then narrow and prune

More use case pointersMore use case pointers

Add pre-conditions and post-conditions in each use case:Add pre-conditions and post-conditions in each use case: What is the state of affairs before and after use case occurs?What is the state of affairs before and after use case occurs? Why?Why?

Some analysts distinguish between business and Some analysts distinguish between business and system use cases:system use cases: System use cases focus on interaction between actors System use cases focus on interaction between actors

within a software systemwithin a software system Business use cases focuses on how a business interacts Business use cases focuses on how a business interacts

with actual customers or eventswith actual customers or events Fowler prefers to focus on business use cases first, Fowler prefers to focus on business use cases first,

then come up with system use cases to satisfy themthen come up with system use cases to satisfy them Note iterative approach in developing use cases, tooNote iterative approach in developing use cases, too

Text and DiagramsText and Diagrams

Use case Use case texttext provides the detailed description provides the detailed description of a particular use caseof a particular use case

Use case Use case diagramdiagram provides an overview of provides an overview of interactions between actors and use casesinteractions between actors and use cases

Use case diagramUse case diagram

Bird’s eye view of use cases for a systemBird’s eye view of use cases for a systemStick figures represent Stick figures represent actorsactors (human or computer in (human or computer in rolesroles))Ellipses are Ellipses are use casesuse cases (behavior or functionality seen by users) (behavior or functionality seen by users)What can user do with the system?What can user do with the system?

E.g., Trader interacts with Trader Contract via a Trade Commodities E.g., Trader interacts with Trader Contract via a Trade Commodities transactiontransaction

<<include>><<include>> relationship inserts a chunk of behavior relationship inserts a chunk of behavior (another use case) (another use case) <<extend>> adds to a more general use case<<extend>> adds to a more general use case

Advantages of use casesAdvantages of use cases

What do you think?What do you think?Systematic and intuitive way to capture functional Systematic and intuitive way to capture functional requirements?requirements?Facilitates communication between user and system analyst:Facilitates communication between user and system analyst: TextText descriptions explain functional behavior in user’s language descriptions explain functional behavior in user’s language DiagramsDiagrams can show relationship between use case behaviors can show relationship between use case behaviors When should we bother with diagrams?When should we bother with diagrams?

Use cases can drive the whole development process:Use cases can drive the whole development process: Analysis understand what user wants with use casesAnalysis understand what user wants with use cases Design and implementation realizes themDesign and implementation realizes them How can use case help with early design of UI prototype?How can use case help with early design of UI prototype? How can use cases set up test plans?How can use cases set up test plans? How can use cases help with writing a user manual?How can use cases help with writing a user manual?

Use cases assignmentUse cases assignment

Develop a set of use cases Develop a set of use cases and a use case diagram for a simple ATMand a use case diagram for a simple ATM(simple means you can just consider two (simple means you can just consider two kinds of accounts, savings and checking, kinds of accounts, savings and checking, and two transactions, deposits and and two transactions, deposits and withdrawals)withdrawals)

Due anytime Sunday, September 7Due anytime Sunday, September 7

on Blackboardon Blackboard

Requirements AssignmentsRequirements Assignments

By Monday, September 8, email me a tentative project title, By Monday, September 8, email me a tentative project title, customer and level of commitment to the project, and other customer and level of commitment to the project, and other team members their roles.team members their roles.

By Monday, September 15, email me a link to a web site By Monday, September 15, email me a link to a web site containing the above (perhaps revised), plus:containing the above (perhaps revised), plus:

1.1. Write a high-level Write a high-level requirements specification 2.2. Write Write uses casesuses cases describing crucial system behavior describing crucial system behavior3.3. Preliminary Preliminary estimatesestimates (person-hours) for project, including (person-hours) for project, including

rest of analysis design, implementation & testingrest of analysis design, implementation & testing4.4. Assess any Assess any risksrisks associated with the project associated with the project