11

The Trouble with The Trouble with RequirementsRequirements

FromFrom

Use Cases – Requirements in Context Second Use Cases – Requirements in Context Second EditionEdition

RUP – Chapter 9 – The Requirements RUP – Chapter 9 – The Requirements DisciplineDiscipline

22

Traditional ActivitiesTraditional Activities Typical development activities include:Typical development activities include:

– business modelingbusiness modeling– requirements gathering, requirements gathering, – analysis and design, analysis and design, – construction, construction, – testing, testing, – deployment and deployment and – maintenance.maintenance.

Frequently given lip service:Frequently given lip service:– Business modelingBusiness modeling– Requirements gatheringRequirements gathering– TestingTesting– DeploymentDeployment– MaintenanceMaintenance

33

Landscape of RequirementsLandscape of Requirements Perception changing from only emphasizing big Perception changing from only emphasizing big

three:three:– Analysis, design, and constructionAnalysis, design, and construction

Realization of criticality of requirements!!Realization of criticality of requirements!! More projects fail due to poor requirements More projects fail due to poor requirements

specification and poor requirements management specification and poor requirements management than for any other reasons.than for any other reasons.

Requirements are Requirements are difficultdifficult to capture to capture– Maybe from drawing, org charts, pure textMaybe from drawing, org charts, pure text– Don’t translate nicely into pure modules that programmers Don’t translate nicely into pure modules that programmers

know and love.know and love.– Difficult for programmers (dealing with the concrete) to Difficult for programmers (dealing with the concrete) to

comprehend comprehend abstractionsabstractions of requirements. of requirements.

44

Landscape of RequirementsLandscape of Requirements We don’t like to spend lots of time hereWe don’t like to spend lots of time here ““Takes too long”Takes too long” We like to plod on (often operating under false We like to plod on (often operating under false

assumptions).assumptions). In fairness:In fairness:

– Huge volumes of requirements (lists) (Tab 1.1)Huge volumes of requirements (lists) (Tab 1.1)– Horribly boringHorribly boring– Difficult to discern critical needs from desires.Difficult to discern critical needs from desires.– Requirements may sometimes be dictated by a single Requirements may sometimes be dictated by a single

person (depending on size of application, this may not person (depending on size of application, this may not be good! – You will get ‘that’ persons views and biases.be good! – You will get ‘that’ persons views and biases.

– ‘‘Analysis paralysis’Analysis paralysis’

55

Goals of Requirements Goals of Requirements DisciplineDiscipline

To establish and maintain agreement with To establish and maintain agreement with the customers and other stakeholders on the customers and other stakeholders on what the system should do and why.what the system should do and why.

To provide system-developers with a better To provide system-developers with a better understanding of the system requirementsunderstanding of the system requirements

To define the boundaries (delimit) of the To define the boundaries (delimit) of the systemsystem

To provide a basis for planning the technical To provide a basis for planning the technical contents of iterationscontents of iterations

To provide a basis for estimating cost and To provide a basis for estimating cost and time to develop the system (RUP – Chap 9)time to develop the system (RUP – Chap 9)

So, what kind of requirements do we have???So, what kind of requirements do we have???

66

Functional and Non-Functional and Non-Functional RequirementsFunctional Requirements

FunctionalFunctional requirements are what the users requirements are what the users need for the system to work.need for the system to work.

Normally we think about those things that the system Normally we think about those things that the system does on behalf of the user.does on behalf of the user.

– ““Need to add, change and delete transactions”Need to add, change and delete transactions”– ““Need to generate ‘this’ report and ‘that’ report…”Need to generate ‘this’ report and ‘that’ report…”

System must be able to do ‘these’ things.System must be able to do ‘these’ things. Non-functionalNon-functional requirements ( requirements (Quality Quality

attributes)attributes) Items like performance, scalability, usability, Items like performance, scalability, usability,

supportability, reliability, security, backup/recovery…supportability, reliability, security, backup/recovery… Normally documented as Supplementary Normally documented as Supplementary

SpecificationsSpecifications Vitally important (sometimes hidden); globalVitally important (sometimes hidden); global

77

Functional RequirementsFunctional Requirements Merely something that the computer application Merely something that the computer application

does for its users. A value or feature!does for its users. A value or feature! Functional requirements are used to express the Functional requirements are used to express the

behavior of a system by specifying both the input behavior of a system by specifying both the input and output conditions that are expected to result.and output conditions that are expected to result.

Sum of requirements => scope of applicationSum of requirements => scope of application– Add requirements? Scope increases…Add requirements? Scope increases…– Scope creep!Scope creep!

Document system functions in the users’ language Document system functions in the users’ language and from users’ perspective!and from users’ perspective!

Requirements indicate specific system responses to Requirements indicate specific system responses to user inputs (interactions).user inputs (interactions).

88

Non-Functional Non-Functional RequirementsRequirements

Non-functional ‘quality’ attributes of system.Non-functional ‘quality’ attributes of system.– Usability –Usability –

Human factors – aestethics, ease of use, learning; Human factors – aestethics, ease of use, learning; consistency in the user interface; training, …consistency in the user interface; training, …

– ReliabilityReliability Addresses the frequency and severity of failure; Addresses the frequency and severity of failure;

recoverability, MTBF, MTTR, etc.recoverability, MTBF, MTTR, etc.– PerformancePerformance

Transaction rates/speeds, availability, response time, Transaction rates/speeds, availability, response time, recovery time…recovery time…

– SupportabilitySupportability Testability, maintainability, …Testability, maintainability, …

Not tied (normally) to specific Not tied (normally) to specific functionsfunctions – – but vital!but vital!

99

RequirementsRequirements Functional RequirementsFunctional Requirements documents user functions and documents user functions and

application features needed by user – (typically end-application features needed by user – (typically end-user especially. But there are lots of stakeholders!)user especially. But there are lots of stakeholders!)– Essential to understand (document/capture/model) stakeholder Essential to understand (document/capture/model) stakeholder

needs!needs!– Need to solicit and capture needs from VARIOUS stakeholders!Need to solicit and capture needs from VARIOUS stakeholders!– Sometimes ‘needs’ are Sometimes ‘needs’ are abstractionsabstractions of the real problems; of the real problems;

behaviors are described. Often not very clear.behaviors are described. Often not very clear. Clear functionality is easier to deal with and can be Clear functionality is easier to deal with and can be

documented/managed using (ahead) Use Casesdocumented/managed using (ahead) Use Cases Non-functionalNon-functional requirements however, normally requirements however, normally

transcend / thread use cases and are often captured in transcend / thread use cases and are often captured in ‘Supplementary Specifications.’‘Supplementary Specifications.’

Together – the functionality (via Use Cases) and non-Together – the functionality (via Use Cases) and non-functional, quality attributes (via the Supplementary functional, quality attributes (via the Supplementary Specifications) constitute the total requirements of the Specifications) constitute the total requirements of the system.system.

1010

Software Requirements Software Requirements Specifications (SRS)Specifications (SRS)

Given inputs from Stakeholder requests, we develop a Given inputs from Stakeholder requests, we develop a Vision Statement Vision Statement – contains key stakeholder needs and high-level featurescontains key stakeholder needs and high-level features

Recognize that this vision statement contains features Recognize that this vision statement contains features with related costs and anticipated ROI. with related costs and anticipated ROI.

Map these desired, high-level features into software Map these desired, high-level features into software requirements from which the system can be developed.requirements from which the system can be developed.

Thus develop a Software Requirements Specification Thus develop a Software Requirements Specification (SRS).(SRS).

SRS consists ofSRS consists of– Detailed requirements via Use Case Models and Use Cases (functional Detailed requirements via Use Case Models and Use Cases (functional

specs)specs)– Requirements that don’t fit in well with Use Cases are captured in the Requirements that don’t fit in well with Use Cases are captured in the

Supplementary Specs (non-functional specs)Supplementary Specs (non-functional specs) The SRS feeds / supports follow on design testing, and The SRS feeds / supports follow on design testing, and

a host of other activities (see fig 9-1 in RUP)a host of other activities (see fig 9-1 in RUP)

1111

HeuristicsHeuristics (an ‘aside’ (an ‘aside’ comment)comment)

Requirements are the ‘WHATs’ of an Requirements are the ‘WHATs’ of an application.application.– Desired functional and non-functional features.Desired functional and non-functional features.

Design is the ‘HOWs’ of an application.Design is the ‘HOWs’ of an application.– specific classes will be used.specific classes will be used.– database / file system; database / file system; – Heavily architecturally-oriented – artifacts, Heavily architecturally-oriented – artifacts,

layers…layers…– platforms, middleware, programming language, platforms, middleware, programming language,

networking approach, etc.networking approach, etc.– Again, HOW do we, as Again, HOW do we, as developersdevelopers, satisfy the , satisfy the

‘Whats’ of the system?‘Whats’ of the system?

1212

Requirements and DesignRequirements and Design

VERY different activitiesVERY different activities Require different mindsets; different people Require different mindsets; different people

and skill sets.and skill sets. Requirements – Requirements – understandingunderstanding the problem the problem

at handat hand Design – Design – solvingsolving the problem the problem

– Clearly, cannot design a solution until the problem Clearly, cannot design a solution until the problem has been identified, documented and understood!has been identified, documented and understood!

1313

Requirements ArtifactsRequirements Artifacts

Inputs:Inputs:– Business Models (Business Use Case; Business Object Business Models (Business Use Case; Business Object

Models; Domain Model)Models; Domain Model)– Stakeholder requests (customers, users, product Stakeholder requests (customers, users, product

managers, developers, etc.) plus how requests were managers, developers, etc.) plus how requests were considered.considered.

Artifacts – SRS:Artifacts – SRS:– Vision Document (not always included here…)Vision Document (not always included here…)– Use Case Model (Use Case Diagrams and Use Case Use Case Model (Use Case Diagrams and Use Case

Narratives)Narratives)– Supplementary SpecificationsSupplementary Specifications

1414

Vision DocumentVision Document

Complete vision of software under Complete vision of software under developmentdevelopment

Basis for funding authority and Basis for funding authority and development organization.development organization.

Written from Customer’s perspective Written from Customer’s perspective focusing on essential features and quality.focusing on essential features and quality.

Includes ‘what’ will be includedIncludes ‘what’ will be included Specifies operations characteristicsSpecifies operations characteristics

– Volumes, response times, user profiles, Volumes, response times, user profiles, interfaces with other systems.interfaces with other systems.

Is the Contractual basis for the Is the Contractual basis for the requirements visible to the stakeholders.requirements visible to the stakeholders.

1515

Use Case ModelUse Case Model

Concentrates on the functionality of Concentrates on the functionality of systemsystem

Can serve as a contract among the Can serve as a contract among the customer, users, and developerscustomer, users, and developers

Consists of Use Case Diagrams, Use Consists of Use Case Diagrams, Use Cases, and ActorsCases, and Actors

Use Cases serve as the unifying thread Use Cases serve as the unifying thread throughout the software lifecycle and throughout the software lifecycle and drives analysis, design, implementation drives analysis, design, implementation and testing.and testing.

1616

Supplementary SpecsSupplementary Specs Normally a text document citing the Normally a text document citing the

‘alities’ required, such as‘alities’ required, such as– UsabilityUsability– ReliabilityReliability– Etc. etc. Etc. etc.

May also include:May also include:– Glossary (from Domain Analysis) - extendedGlossary (from Domain Analysis) - extended– Domain Model (from Domain Analysis) – Domain Model (from Domain Analysis) –

extended / modifiedextended / modified– Storyboards (serve as basis for User Interface Storyboards (serve as basis for User Interface

Prototypes) – developed from Use Cases.Prototypes) – developed from Use Cases. Typically developed ‘in parallel’ with other Typically developed ‘in parallel’ with other

requirements activities.requirements activities.

1717

Challenges of Requirement Challenges of Requirement GatheringGathering

Some state: “Users do NOT know what they want.”Some state: “Users do NOT know what they want.”– SometimesSometimes this is very true; sometimes this is very true; sometimes NOTNOT..– Users have lots on their minds besides your application!!Users have lots on their minds besides your application!!

Sometimes users won’t commit to written requirements;Sometimes users won’t commit to written requirements; Communication with users is often very low. Communication with users is often very low. Conflicts in performing today’s job and in shaping a new system Conflicts in performing today’s job and in shaping a new system

– ‘resistance to change.’– ‘resistance to change.’– Requirements change dynamically…the more ‘seen’ the Requirements change dynamically…the more ‘seen’ the

more wanted!more wanted!– Remember: it is the Remember: it is the usersusers who must be satisfied! who must be satisfied!– Real problems: we need to recognize the conflicts users Real problems: we need to recognize the conflicts users

have between their daily jobs and how you need that same have between their daily jobs and how you need that same ‘time’ to help shape the developing system.‘time’ to help shape the developing system.

Best approach is to work so very hard at establishing Best approach is to work so very hard at establishing personal relationships with users! So very essential!personal relationships with users! So very essential!

1818

What to do?What to do? Understand the User’s Understand the User’s divideddivided attentions… attentions… Establish a relationshipEstablish a relationship with your users (again) with your users (again)

– Make it personalMake it personal– They will make more meetings, reviews, and answer They will make more meetings, reviews, and answer

more questionsmore questions Make project more visibleMake project more visible

– EscalateEscalate the importance of system to senior level the importance of system to senior level executives, if possibleexecutives, if possible

– If If seniors are “awareseniors are “aware,” more likely users will attend ,” more likely users will attend requirement sessions, interview sessions, etc.requirement sessions, interview sessions, etc.

Be respectful of others’ timeBe respectful of others’ time!!– Batch questions, interviews together…Batch questions, interviews together…

1919

More on Requirements More on Requirements Gathering and SpecificationGathering and Specification

Have reviews to avoid conflictHave reviews to avoid conflict Try to avoid conflicting requirementsTry to avoid conflicting requirements The larger the volume, the less likely The larger the volume, the less likely

project will succeed.project will succeed. Establish requirements traceability!!Establish requirements traceability!!

– Requirements should be Requirements should be traceabletraceable throughout the effort throughout the effort backback to the to the requirements specification.requirements specification.

2020

Requirements Requirements TraceabilityTraceability

Questions that should be answerableQuestions that should be answerable::– Analyst/designerAnalyst/designer – – Where did this requirement come from? Where did this requirement come from?

Within a class, what requirement does this Within a class, what requirement does this methodmethod satisfy? Where is satisfy? Where is it specified?it specified?

– DeveloperDeveloper – – What specific requirements does the class you’re What specific requirements does the class you’re programming relate to? Executing this method satisfies programming relate to? Executing this method satisfies whatwhat requirement(s)?requirement(s)? Many more details on class contents (parameters…)Many more details on class contents (parameters…) Heavily architecture-dependent; Oftentimes multiple Heavily architecture-dependent; Oftentimes multiple

components are needed to satisfy individual requirements.components are needed to satisfy individual requirements.

– TesterTester – – When you execute this ‘test case,’ what exact requirement When you execute this ‘test case,’ what exact requirement / requirements are you testing for? Can you find it in the / requirements are you testing for? Can you find it in the requirements specification?requirements specification?

2121

Standard Approaches (1 of 4) Standard Approaches (1 of 4) User Interviews:User Interviews:

– Trying to learn how users do their jobs now, how they expect Trying to learn how users do their jobs now, how they expect their jobs to change, and typical problems they encounter now.their jobs to change, and typical problems they encounter now.

– Interview different people at different levels – note biases / Interview different people at different levels – note biases / conflictconflict We get ‘their’ perspectiveWe get ‘their’ perspective Customer, end-user, client, etc…Customer, end-user, client, etc…

User QuestionnairesUser Questionnaires– lots of pros/cons. Many ‘types’ and ways to administer… Lots of lots of pros/cons. Many ‘types’ and ways to administer… Lots of

philosophies on creating types of questions – open-ended, philosophies on creating types of questions – open-ended, closed, etc., and methods to evaluate the responses (if any…)closed, etc., and methods to evaluate the responses (if any…)

Web pages – org chart; mission; services…Web pages – org chart; mission; services… Annual Reports – what’s going on? Marketing…Annual Reports – what’s going on? Marketing… Newsletters – See local happenings; sometimes more Newsletters – See local happenings; sometimes more

globalglobal

2222

Standard Approaches (2 of Standard Approaches (2 of 4)4)

Joint Requirements Planning Sessions Joint Requirements Planning Sessions (JRPS)(JRPS) – Conduct all interviews at same time in same room.Conduct all interviews at same time in same room.– All key people brought together.All key people brought together.– Have facilitator, scribe, projectors, and support Have facilitator, scribe, projectors, and support

software…software…– Focus is on WHAT the system Focus is on WHAT the system – Have representatives of all key stakeholdersHave representatives of all key stakeholders– High-level topics (in JRP) are first: critical success High-level topics (in JRP) are first: critical success

factors, strategic opportunities, vision, risks, business factors, strategic opportunities, vision, risks, business rules, …rules, …

– Functional/non-functional requirements identified, Functional/non-functional requirements identified, documented, and prioritized. documented, and prioritized. OWNERSHIP!!OWNERSHIP!!

– Normally conducted off-site.Normally conducted off-site.– Artifact: the document produced: a list of Artifact: the document produced: a list of

requirements. (List? Ech!)requirements. (List? Ech!)

2323

Standard Approaches (3 of Standard Approaches (3 of 4) 4)

Requirements ListsRequirements Lists– Problems with Requirements ListsProblems with Requirements Lists– Most people detest requirement lists!Most people detest requirement lists!– Replace with Use Cases, Use Case diagrams, and Replace with Use Cases, Use Case diagrams, and

business rules replace the requirements lists. business rules replace the requirements lists. (Coming!)(Coming!) But not always; Requirements lists are sometimes used But not always; Requirements lists are sometimes used

at very early stages for stakeholders and clearly at very early stages for stakeholders and clearly differentiating sub-requirements (alternatives, differentiating sub-requirements (alternatives, exceptions, …)exceptions, …)

– Review sample requirements lists: pp. 17-19.Review sample requirements lists: pp. 17-19.

2424

Standard Approaches (4 of 4)Standard Approaches (4 of 4) PrototypesPrototypes

– Pros:Pros:– Very popular in mid 1980sVery popular in mid 1980s– Are mock-ups of screens and/or windowsAre mock-ups of screens and/or windows– Primarily used do Primarily used do define user interfacesdefine user interfaces which means which means

functionality!!!functionality!!!– Great user-interface prototyping tools available – e.g. VB is Great user-interface prototyping tools available – e.g. VB is

super for UI capture.super for UI capture.– ExtremelyExtremely conducive to communications between user groups conducive to communications between user groups

and developers.and developers.– Early changes to screens set stage for fewer changes later and Early changes to screens set stage for fewer changes later and

reduced overall costs!reduced overall costs!– Greatly facilitates stakeholder acceptance later…Greatly facilitates stakeholder acceptance later…

2525

Standard Approaches (4 of Standard Approaches (4 of 4)4)

PrototypesPrototypes– Cons:Cons:

But, some pay more attention to screen than to But, some pay more attention to screen than to functionality.functionality.

Executives sometimes fail to realize that prototype is not Executives sometimes fail to realize that prototype is not a working system.a working system.

Want it right awayWant it right away A throwaway – Get buy-in up front on the throw-away – A throwaway – Get buy-in up front on the throw-away –

unless the development strategy (small systems) is to unless the development strategy (small systems) is to hone the prototype into a compliant application).hone the prototype into a compliant application).

Prototypes imply more is ‘done’ than is done.Prototypes imply more is ‘done’ than is done. Only represent front end (presentation) and do not Only represent front end (presentation) and do not

usually represent the business rules.usually represent the business rules. At best (but very good!) a great way to determine the At best (but very good!) a great way to determine the

user interface specification.user interface specification.

2626

Most popular way to capture Most popular way to capture functional requirements is the Use functional requirements is the Use Case: a widely-adhered to Case: a widely-adhered to technology.technology.

Enter: Use CasesEnter: Use Cases