11
Requirements Analysis I Requirements Analysis I
FromFrom
Book: Use Cases – Requirements in Context Second Edition Book: Use Cases – Requirements in Context Second Edition
Book: RUP – Chapter 9 – The Requirements Discipline Book: RUP – Chapter 9 – The Requirements Discipline
Article: “The Role of Requirements Traceability in System Article: “The Role of Requirements Traceability in System Development” – by Dean Leffingwell, copyright: Rational Development” – by Dean Leffingwell, copyright: Rational
Software, 2002. h Software, 2002. h
ttp://www.therationaledge.com/content/sep_02/m_requiremen ttp://www.therationaledge.com/content/sep_02/m_requiremen
tsTraceability_dl/.jsp tsTraceability_dl/.jsp
Traditional Activities Traditional 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
3/373/37
Landscape of Requirements Landscape of Requirements
Perception changing from only emphasizing big three:
– Analysis, design, and construction
Increasing Realization of criticality of
– Business Modeling and
– Requirements - their verification and traceability.
More projects fail due to poor requirements
specification and poor requirements management than for any other reasons.
– that is, Changing Requirements and their management and scope creep – usually ‘not formal’ but ever-present!
Requirements: Difficult to Capture Requirements: Difficult to Capture
Sometimes done by BA (Business Analysts); sometimes done by System Analysts - But not always!
Sometimes (especially BAs)they have difficulty in mapping abstract “needs” to “features” understandable by
developers…
Sometimes done by developers with much input from BAs (know the environment) and SAs and others.
Typically developers have limited knowledge of application domain.
Developers often have difficulty communicating with Business Analysts and others.
5/375/37
Landscape of Requirements Landscape of Requirements
Often developers don’t like to spend lots of time here (we should, but we don’t)
“Takes too long”
Developers like to plod on (often operating under false assumptions).
In fairness:
– Requirements can take form of huge requirements lists – Horribly boring
– Difficult to discern critical needs from desires.
– Requirements may sometimes be dictated by a single person (depending on size of application, this may not be good! – You will get ‘that’ person’s views and biases.
Goals of Requirements Discipline Goals of Requirements Discipline
To establish and maintain agreement with the To establish and maintain agreement with the customers and other stakeholders on
customers and other stakeholders on whatwhat the the system should do and why.
system should do and why.
To provide system-developers with a better To provide system-developers with a better understanding of the
understanding of the system requirementssystem requirements
To define To define boundariesboundaries (delimit) of the system (delimit) of the system
To provide a To provide a basis for planningbasis for planning the technical the technical contents of iterations
contents of iterations
To provide a To provide a basis for estimating cost and timebasis for estimating cost and time to develop the system
to develop the system
7/37
Functional and Non-Functional Requirements
Functional requirements are what the users need for the system to work.
“Need to add, change and delete transactions”
“Need to generate ‘this’ report and ‘that’ report…”
System must be able to do ‘these’ things.
System must be learnable; have utility; be usable!!
Non-functional requirements (
Quality attributes) Items like performance, scalability, usability,
supportability, reliability, security, backup/recovery…
Normally documented: Supplementary Specifications
Vitally important (sometimes hidden); global
Functional Requirements Functional Requirements
Merely something that the computer application does for its users. A value or feature!
Functional requirements are used to express the behavior of a system by specifying both the input and output conditions that are expected to result.
Sum of requirements => scope of application – Add requirements? Scope increases…
– Scope creep! (Discuss…)
Requirements indicate specific system responses to user inputs (behaviors; interactions).
9/37
Non-Functional Requirements
Non-functional ‘quality’ attributes of system.
– Usability –
Human factors – aesthetics, ease of use, learning; consistency in the user interface;
training, …
– Reliability
Addresses the frequency and severity of failure; recoverability…
– Performance
Transaction rates/speeds, availability, response time, recovery time
– Supportability
Testability, maintainability, …
– Security
Application is protected from unauthorized access. (or parts of it)
Not tied (normally) to specific functions – but vital!
Often thread many requirements.
Requirements Artifacts Requirements Artifacts
Inputs: From Business Modeling
– Business Models (Business Vision document, Business Use Case; Business Object Models; Domain Model, Risks Lists, Business Rules, etc.)
Outputs: Requirements Artifacts – Software Requirements Specification (SRS)- Produced:
– Product Vision Document – (application to be developed)
Contains Needs and Features.
– Functional Specifications as captured in the Use Case Model (Use Case Diagrams and Use Case Specs)
– Supplementary Specifications (local conventions – ways or procedures for doing things) - Non-functional requirements, and a number of other things – Schedule, ROI, Anticipated conversions, etc.
11/3711/37
The Pecking Order The Pecking Order
So HOW do we elicit and capture (model) the Requirements? Let’s go backwards:
– Requirements (captured in Use Cases and in Supplementary Specs) are identified to support a given Feature / Features captured as
Stakeholder Needs in the Vision document for the Application.
Thus we have a mapping:
Needs Features Use Cases / Supp Specs
13/3713/37
Traceability Traceability
We have a ‘traceability relationships.’
We have a ‘traceability relationships.’
–NeedsNeeds – –
Captured Captured Needs (desires) obtained from Stakeholders must Needs (desires) obtained from Stakeholders must TRACE
TRACE toto specific specific FeaturesFeatures (functional requirements) which map (functional requirements) which map ((tracetrace toto) to specific requirements) to specific requirements as captured via ‘stories’ in as captured via ‘stories’ in
Use Cases and the Supplementary Specifications.
Use Cases and the Supplementary Specifications.
–A A NeedNeed may be ‘fulfilled by’ or is ‘part of’ or some kind of may be ‘fulfilled by’ or is ‘part of’ or some kind of feature
feature, etc., etc.
So, such So, such traceability relationshipstraceability relationships (much in the literature!) are (much in the literature!) are essential
essential to developing quality applications and to assure to developing quality applications and to assure stakeholder needs are indeed accommodated in the resulting stakeholder needs are indeed accommodated in the resulting
application.
application.
Product Vision Document Product Vision Document
Complete visionComplete vision of software under development of software under development
Basis for funding authority and development Basis for funding authority and development organization.
organization.
Written from cWritten from customer’sustomer’s perspective perspective focusing focusing on essential
on essential featuresfeatures and and qualityquality..
Includes ‘Includes ‘whatwhat’ will be included’ will be included
Captures User Captures User NeedsNeeds and and FeaturesFeatures..
Specifies operations and characteristicsSpecifies operations and characteristics
– Volumes, response times, user profiles, interfaces with other Volumes, response times, user profiles, interfaces with other systems.
systems.
Is the Is the Contractual basisContractual basis for the requirements for the requirements
15/3715/37
Functional Specifications
Functional Specifications captured in captured in the Use Case Model / Specification the Use Case Model / Specification
Concentrates on the Concentrates on the functionalityfunctionality of system of system
Can serve as a contract among the customer, users, and Can serve as a contract among the customer, users, and developers
developers
Consists of Use Case Consists of Use Case DiagramsDiagrams, , Use Case SpecificationsUse Case Specifications (or use case narratives or descriptions) and
(or use case narratives or descriptions) and ActorsActors
Use Cases serve as the Use Cases serve as the unifying threadunifying thread throughout the throughout the software lifecycle and
software lifecycle and drivedrive analysis, design, analysis, design,
implementation, testing, iteration planning, software implementation, testing, iteration planning, software architecture, interface prototype development, and a
architecture, interface prototype development, and a hosthost of of additional activities. (
additional activities. (This is a This is a very important concept)very important concept)
Supplementary Specifications Supplementary Specifications
Normally a text document citing the ‘-abilities’ Normally a text document citing the ‘-abilities’
required, such as required, such as
– Usability, Scalability, Maintainability, Efficiency, Reliability, Usability, Scalability, Maintainability, Efficiency, Reliability, Portability, etc.
Portability, etc.
– Sometimes considered as Sometimes considered as constraintsconstraints on designon design! Good!!! Good!!
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) – extendedextended / / modified
modified
– Storyboards (serve as basis for User Interface Prototypes) – Storyboards (serve as basis for User Interface Prototypes) – developed from Use Cases.
developed from Use Cases.
17/3717/37
Stakeholder Needs Stakeholder Needs
Stakeholder needs may arise from a variety Stakeholder needs may arise from a variety of sources, as explained in the past.
of sources, as explained in the past.
Questionnaires, Interviews, Quarterly Questionnaires, Interviews, Quarterly
Reports, Newsletters, Web pages, Annual Reports, Newsletters, Web pages, Annual
Reports; Stockholder reports; Consortia of Reports; Stockholder reports; Consortia of
corporations, etc. are but a few.
corporations, etc. are but a few.
The list is rather endless. The list is rather endless.
Let’s look at a few. Let’s look at a few.
Standard Approaches (1 of 5) Standard Approaches (1 of 5)
User InterviewsUser Interviews:: Try to learn Try to learn
– how users do their jobs now, how users do their jobs now,
– how they expect their jobs to change, and how they expect their jobs to change, and – typical problems they encounter now.typical problems they encounter now.
Interview different people at different levels – note biases / conflictInterview different people at different levels – note biases / conflict
We get ‘their’ perspectiveWe get ‘their’ perspective
Customer, end-user, client, etc…Customer, end-user, client, etc…
User QuestionnairesUser Questionnaires
– lots of pros/cons. lots of pros/cons.
– Many ‘types’ and ways to administer… Lots of philosophies on creating types Many ‘types’ and ways to administer… Lots of philosophies on creating types of questions – open-ended, closed, etc., and methods to evaluate the
of questions – open-ended, closed, etc., and methods to evaluate the responses (if any…)
responses (if any…)
19/3719/37
Standard Approaches (2 of 5) Standard Approaches (2 of 5)
Joint Requirements Planning Sessions (JRPS)Joint Requirements Planning Sessions (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 software…Have facilitator, scribe, projectors, and support software…
– Focus is on WHATs ofFocus is on WHATs of the system the system
– Have representatives of Have representatives of all key stakeholdersall key stakeholders
– High-level topics (in JRP) are first: critical success factors, High-level topics (in JRP) are first: critical success factors, strategic opportunities, vision, risks, business rules, …
strategic opportunities, vision, risks, business rules, … – Functional/non-functional requirements identified, Functional/non-functional requirements identified,
documented, and prioritized together!!
documented, and prioritized together!! OWNERSHIP!!OWNERSHIP!!
– Often conducted off-site.Often conducted off-site.
– Artifact: the document produced: a list of requirements. Artifact: the document produced: a list of requirements.
(List? Ech!) (List? Ech!)
Standard Approaches (3 of 5) Standard Approaches (3 of 5)
Requirements Lists – Functional Specs
– Problems with Requirements Lists – Most people detest requirement lists!
Replace with Use Case Specifications, Use Case diagrams, and business rules.
– Not always replaceable: Requirements lists are sometimes used at very early stages for stakeholders and clearly
differentiating sub-requirements (alternatives, exceptions, …
21/3721/37
Standard Approaches (4 of 5) Standard Approaches (4 of 5)
Prototypes - Pros:
– Are mock-ups of screens and/or windows
– Often used do define user interfaces which implies functionality!!!
Great user-interface prototyping tools available –
Extremely conducive to communications between user groups and developers.
Early changes to screens set stage for fewer changes later and reduced overall costs!
Greatly facilitates stakeholder acceptance later…
Standard Approaches (5 of 5) Standard Approaches (5 of 5)
Prototypes - Cons:
– But, some pay more attention to screen than functionality.
– Executives may fail to realize prototype is not a working system.
– Want it right away
– A throwaway – Get buy-in on the throw-away – unless the development strategy (small systems) is to hone the
prototype into a compliant application).
– Prototypes imply more is ‘done’ than is done.
Only represent front end (presentation) and do not usually represent the business rules. up front
23/3723/37
Statement of
Statement of Need Need
“The system will allow students to register for courses, and change their registration, as simply and rapidly as possible. It will help students
achieve their personal goals of obtaining their degree in the shortest reasonable time while taking courses that they find most interesting and fulfilling.” (p. 107, OOSE)
Very meaningful to the Stakeholder.
Map: Needs to
Map: Needs to Features Features
Define features of system that meets needs of the stakeholders.
While performing this step, it can be helpful to continually relate the features of your
proposed solution back to user needs.
This may be accommodated using a mechanism (simple table) called a traceability matrix.
25/3725/37
xx xx
xx xx
xx xx
Need #1
Feature #1
…
Need #n Need #2
Feature #2 … Feature #m
Traceability Matrix – Leffingwell article
The Stakeholder needs are in the first column and the application features that we have defined to meet those needs constitute the columns.
Features are normally found in the Product Vision document for the Application.
Traceability Matrix
Traceability Matrix (more) (more)
We put Xs in the cells under the features that we have defined to satisfy the stakeholder needs.
Please note that this is a 1:n mapping, as there are far more features than explicitly stated Needs.
Further, the Needs are at high levels of abstraction.
Study matrix.
No X under a feature? Perhaps Need is not mapped into feature(s)! Flag!!
Features not traced back to a Need? Perhaps we have Features that are not traceable back to Needs!
27/3727/37
Needs to Feature Mapping Needs to Feature Mapping
Maybe the Needs or Features are not clear!Maybe the Needs or Features are not clear!
Too, we are Too, we are notnot dealing with a dealing with a lot of informationlot of information here, so this traceability should be undertaken.
here, so this traceability should be undertaken.
Leffingwell: “Once you've mapped the need-feature relationships and have determined that the needs and features are correctly accounted for and understood, it's time to consider the next level of the hierarchy:
Relationships between the features and the use cases.”
Continue the Traceability Continue the Traceability
Mapping Mapping
From the From the Product Vision Document Product Vision Document for the Application, which contains the for the Application, which contains the
desired
desired Features Features derived from derived from Stakeholder
Stakeholder Needs Needs , we need to , we need to map map the Features to
the Features to Use Cases Use Cases . .
Consider the next two slides: Consider the next two slides:
2929/29/29
We continue with this figure – to the figure on the next slide…
Product Features, and more
