View
225
Download
2
Tags:
Embed Size (px)
Citation preview
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.