Requirements Requirements specificationspecification

CSE432CSE432

Object-Oriented Object-Oriented Software EngineeringSoftware Engineering

Requirements analysis and Requirements analysis and system specificationsystem specification

Why is this the first stage of most life cycles?Why is this the first stage of most life cycles? Need to understand what customer wants first!Need to understand what customer wants first!

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

Some call this step Some call this step requirements gatheringrequirements gathering Requirements are a Requirements are a contractcontract between you and the customer (OOSE theme) between you and the customer (OOSE theme)

System specification says: “Here’s a description of System specification says: “Here’s a description of whatwhat the program the program will do (not will do (not howhow) to satisfy the requirements.” ) to satisfy the requirements.”

Some distinguish requirements gathering and system analysis stepsSome distinguish requirements gathering and system analysis steps A top-level exploration into the problem and in some sense a discovery A top-level exploration into the problem and in some sense a discovery

of whether it can be done and how long it will takeof whether it can be done and how long it will takeGoal of requirements elicitation is to understand the customer’s problemGoal of requirements elicitation is to understand the customer’s problem

Though customer may not fully understand it!Though customer may not fully understand it!

""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 the teamFosters initial buy-in and agreement by everyone on the team Real-world specsReal-world specs are usually much longer, though are usually much longer, though

What’s the purpose of a What’s the purpose of a purposepurpose statement? statement?Why is Why is scopescope important? important?Why Why definitionsdefinitions??Other possible general requirements:Other possible general requirements:

Business contextBusiness context: organization sponsoring the development of : organization sponsoring the development of the productthe product

User characteristicsUser characteristics: profile of user community, expected : profile of user community, expected expertise with system & domainexpertise with system & domain

User objectivesUser objectives: “wish list” from user’s perspective, in line with : “wish list” from user’s perspective, in line with business objectivesbusiness objectives

Interface requirementsInterface requirements: GUI, API, communication interfaces, : GUI, API, communication interfaces, software interfacessoftware interfaces

Functional and non-functional Functional and non-functional requirementsrequirements

FunctionalFunctional requirements describe system behavior requirements describe system behavior Priority: Priority: rank order the requirements in importancerank order the requirements in importance CriticalityCriticality: how essential is each requirement to the overall : how essential is each requirement to the overall

system?system? RisksRisks: when might a requirement not be satisfied? What can be : when might a requirement not be satisfied? What can be

done to reduce this risk?done to reduce this risk?

Non-functionalNon-functional requirements describe other desired requirements describe other desired system attributessystem attributes

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)

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. Correct: does what the client wants.

This quality is like motherhood and apple pie—This quality is like motherhood and apple pie—How can you accomplish this?How can you accomplish this? Ask the client: keep a list of questions for the clientAsk the client: keep a list of questions for the client Prototyping: explore the risky aspects of the system with the clientPrototyping: explore the risky aspects of the system with the client

Verifiable: can determine whether the requirements have been metVerifiable: can determine whether the requirements have been met But how do verify a requirement like “user-friendly” or “it should never crash”?But how do verify a requirement like “user-friendly” or “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 "Start/Stop" in anotherIf you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another

Complete: has everything designers need to create the softwareComplete: has everything designers need to create the softwareUnderstandable: stakeholders understand it well enough to buy into itUnderstandable: stakeholders understand it well enough to buy into it

Can there be a tension between understandability and the other desiderata?Can there be a tension between understandability and the 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 cases

First developed by Ivar Jacobson First developed by Ivar Jacobson Now part of the UMLNow part of the UML 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 deposited a 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 account without check within 24 hours and there’s not enough in the account without the check to provide the desired withdrawal?”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

Why are use cases good for brainstorming requirements?Why are use cases good for brainstorming requirements?

Text and DiagramsText and Diagrams

Use case text provides the detailed description of Use case text provides the detailed description of a particular use casea particular use case

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

Example use caseExample use case

(from Fowler and Scott, (from Fowler and Scott, UML DistilledUML Distilled)) Use Case: Buy a ProductUse Case: Buy a Product1.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 delivery)Customer fills in shipping information (address; next-day or 3-day 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 customerSystem sends confirming email to customer

Alternative: Alternative: Authorization FailureAuthorization Failure6a.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-try

Alternative:Alternative: Regular customer Regular customer3a. 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

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 (another relationship inserts a chunk of behavior (another use case) use case) <<extend>> adds to a more general use case<<extend>> adds to a more general use case

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 even specific people or IF-THEN-ELSE or GUI elements or even specific people or departmentsdepartments

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 user cases with the user’s vocabulary, the way a users would Write user cases with the user’s vocabulary, the way a users would describe performing the taskdescribe 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 that Actors can be people, computer systems or any external entity that initiate an action. initiate an action.

A use case interaction produces something of value to an actor.A use case interaction produces something of value to an actor.Create use cases and requirements incrementally and iterativelyCreate use cases and requirements incrementally and iteratively

Start with an outline or high-level descriptionStart with an outline or high-level description Work from a problem statement and statement of work (scope)Work from a problem statement and statement of work (scope) 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 the use case occurs?What is the state of affairs before and after the use case occurs? Why?Why?

Some analysts distinguish between business and system Some analysts distinguish between business and system use cases: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

Advantages of use casesAdvantages of use cases

What do you think?What do you think?Systematic and intuitive way to capture functional requirements?Systematic and intuitive way to capture functional requirements?Facilitates communication between user and system analyst?Facilitates communication between user and system analyst?

TextText descriptions of Actors and Use Cases can supplement diagrams descriptions of Actors and Use Cases can supplement diagrams DiagramsDiagrams can help identify objects & show state/transition flow can help identify objects & show state/transition flow

Drives the whole development process?Drives the whole development process? Analysis starts with use casesAnalysis starts with use cases Design and implementation realizes themDesign and implementation realizes them 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?

How can use case help with early design of user interface prototype?How can use case help with early design of user interface prototype?Implementation details or language can be added to use cases Implementation details or language can be added to use cases later in the life cycle?later in the life cycle?

So, how will So, how will youyou do do requirements gathering and specification?requirements gathering and specification?