Weitere ähnliche Inhalte
Mehr von Scott Althouse (7)
Kürzlich hochgeladen (20)
Writing eliciting good rqmts 082311
- 1. © 2011 IBM Corporation
Michelle Specht
Writing and Eliciting Good Requirements
Michelle Specht
7/23/2011
- 2. © 2011 IBM Corporation
Software and Systems Engineering | Rational
2
Agenda
The Importance of Good Requirements
The Challenges of Developing Good Requirements
Writing Requirements
Requirements Elicitation
Using Requirements Management tools
- 3. © 2011 IBM Corporation
Michelle Specht
The Importance of Good Requirements
- 4. © 2011 IBM Corporation
Software and Systems Engineering | Rational
4
If you do not know
where you are
going….you will
wind up
somewhere else!!
Yogi Berra
Most of us have learned this lesson
and it is why we value requirements as
a critical part of systems and software
development
Why We Need Requirements
- 5. © 2011 IBM Corporation
Software and Systems Engineering | Rational
5
Requirements Definition and Management Business Realities
Traditional methods yield excess rework, delays & poor quality
20
200
RelativeCosttoRepair
AcceptanceQA TestCodingDesignAnalysis
0
Maintenance
10
5
50
1-2
Lost Opportunity
Late to market by 6
months or more will
cost organizations
33% of the 5-year
ROI
41% of projects fail
to deliver expected
business ROI
49% of projects
overrun original
estimates
-Standish Group
Cost
70-80% of
development costs
are spent
identifying
and correcting
defects
More than 40% of
development
budget will be
consumed by poor
requirements
- 6. © 2011 IBM Corporation
Software and Systems Engineering | Rational
6
The purpose of requirements and requirement management
Requirements and Requirement management need to do
two things:
1) Validate - Make sure you are building the right product:
Are we doing the right thing?
2) Verify - Make sure you built the product right:
Are we doing the thing right?
- 7. © 2011 IBM Corporation
Software and Systems Engineering | Rational
7
What can happen when Requirements are not done right:
- 8. © 2011 IBM Corporation
Michelle Specht
The Challenges of Developing Good Requirements
- 9. © 2011 IBM Corporation
Software and Systems Engineering | Rational
9
Poor Requirements Practices Pose Significant Challenges
Across Teams
We struggle with budgets and
can’t consistently meet
customer needs
Executive
Analyst
It’s hard to accurately capture
requirements & make sure
they are implemented &
tested
We can’t keep up with
requirement changes and
know what is most important
to develop and test
Development and
Test teams
Quality Manager
Improve
Quality
Efficiency
+
Innovation
Reduce
Cost
Accelerate
Delivery
Time
We are continuously pushed to
increase quality with less
resources!
- 10. © 2011 IBM Corporation
Software and Systems Engineering | Rational
10
Safety
Regulatory compliance
Development timescales
Project scale
Project life
…
Cost
Quality Time
Different industries have different needs…
- 11. © 2011 IBM Corporation
Software and Systems Engineering | Rational
11
Engineers like to solve problems
Measure twice, cut once Look before you leap
Thinking before you act saves time, money, effort and improves quality. It’s plain
common sense, yet, when it comes to requirements management, this common
sense seems not to be there. Many projects start before thought has been put into
the project’s purpose, its desired results, and how its success will ultimately be
measured.
- 12. © 2011 IBM Corporation
Software and Systems Engineering | Rational
12
Working with Requirements is a lifecycle activity
You need to enable requirements to evolve during the lifecycle
– Increase the likelihood of delivering value early
– Minimizes risk
– Minimizes re-work
– Reduces confusion
– Improves quality
- 13. © 2011 IBM Corporation
Software and Systems Engineering | Rational
13
Requirements are always changing
Changes in environment (e.g. new threats) lead to changes in
stakeholder needs
Changes in technology (e.g. cheaper memory) lead to new
stakeholder requirements and possible solutions that are cheaper,
faster, etc.
Changes in stakeholders (e.g. new customer in charge) lead new
views and new stakeholder requirements
Changes in budget ( e.g. funding cut) funding lost
And the longer your development timescale the greater the chance
that requirements will change during your project
- 14. © 2011 IBM Corporation
Software and Systems Engineering | Rational
14
Requirements come from everywhere
Requirements
- 15. © 2011 IBM Corporation
Software and Systems Engineering | Rational
15
People over design
Programs are getting so complex put solutions do not always need to be
complicated. The simplest solution is usually the best. John Deere fuel
tank sight gauge is a great example of this
- 16. © 2011 IBM Corporation
Software and Systems Engineering | Rational
16
There are many different types of requirements
Stakeholder Requirements
Architectural Requirements
Structural Requirements
Behavioral Requirements
SystemsFunctional Requirements
Non-functional Requirements
Performance Requirements
Design Requirements
Derived Requirements
Allocated Requirements
……….
- 17. © 2011 IBM Corporation
Software and Systems Engineering | Rational
17
Factors which complicate Requirements Management
Multiple requirement sets
Large number of requirements
Different levels of requirements
Version control
Change control
Product lines
Distributed teams
Different processes
Impact of changes
Systems of systems
Convergence of old and new technologies
- 18. © 2011 IBM Corporation
Michelle Specht
Writing Requirements
- 19. © 2011 IBM Corporation
Software and Systems Engineering | Rational
19
Requirement Writing
The art of writing requirements takes great skill and, like writing code,
the end result is usually cleaner and more consistent if there’s a
single author.
Don’t expect to get the requirements 100% correct. You need to
allow for human nature and use the same language as your client.
The following guideline gives 13 tips on how to write better
requirements by following simple rules for word selection and
sentence structure.
Most of these guidelines only apply to the requirement statements,
not the complete specification.
- 20. © 2011 IBM Corporation
Software and Systems Engineering | Rational
20
Requirement Writing
1: Use the simplest words appropriate to state a complete requirement.
– An eloquently written requirement is probably not a good one.
– A requirement must be written so many different people can
understand it.
- 21. © 2011 IBM Corporation
Software and Systems Engineering | Rational
21
Requirement Writing
2: Use requirement imperatives correctly.
– Use company/program defined list.
– If requirements are from a non-company source, make sure you know the
meaning of these words. (Definitions should be included in Section 1 of the
specification)
Common imperative definitions;
“Shall” Definition
“Shall” denotes a mandatory and contractual requirement. “Shall” requires metrics to quantify
and requires a verification process.
“Will” Definition
“Will” denotes a mandatory and contractual requirement. It is similar to “shall” but does not
require metrics or verification.
“Should” Definition
“Should” denote a design goal, an objective the system tries to meet.
- 22. © 2011 IBM Corporation
Software and Systems Engineering | Rational
22
Requirement Writing
Adequate
As Appropriate
Bad
Better
But not limited to
Correct
Easy
Effective
Ideal
Large
Maximize
Minimize
Most
Must
Necessary
Normal
Quick
Rapid
Readily
Relevant
Satisfactory
Shall not
Small
Sufficient
Suitable
Timely
Typical
User friendly
Was
3: Do not use weak phrases and subjective words.
Following are words and phases not to use when writing a requirement:
- 23. © 2011 IBM Corporation
Software and Systems Engineering | Rational
23
Requirement Writing
4: Use continuations carefully, they make traceability and verification
difficult. Use when all items are to be verified by the same method at the
same time.
Example:
– The system shall report software status to the host interface under the following conditions:
• At system initialization.
• When the status of an external interface has changed.
• When a report has been requested.
5: Use examples, tables, figures etc., they are a great source of
information and clarification.
– Make sure examples and notes are clearly marked as such (not part of requirement).
– For tables; specify if all, some or none of the cells are requirements.
– Clearly indicate if a figure or part of the figure, is part of the requirement, or is information.
- 24. © 2011 IBM Corporation
Software and Systems Engineering | Rational
24
Requirement Writing
6: Be consistent with names; always call the same entity by the same name.
– Example: If in some requirements the subject is called “the System,” and in others “ the URQ-65”, the
names are not consistent.
– Always use the correct name for the level of specification. You can not verify a sub capability at a
systems level.
7: If you use a TBD or TBR, have a plan. You must state who is responsible for
the information, and when the it will be completed.
- 25. © 2011 IBM Corporation
Software and Systems Engineering | Rational
25
Requirement Writing
8: Make sure a requirement contains all the qualities of a good requirements
– Concise: Minimal, easily understood, a complete expression of a single thought, non-ambiguous; only
one possible interpretation.
– Correct: An absence of errors of fact.
– Consistent: No conflicts between individual requirements, parts of a single requirement complement
each other. Connectivity exists between the requirements; consistent words and terms
– Traceable: Know source of requirement and be able to allocate it, Uniquely identified for life. Never re-
used identification on Project.
– Verifiable: Method (Test, Inspection, Demonstration, Analysis, Certification) Understand how
requirement can be verified, and determine criteria for acceptance.
– Necessary: Can the system be complete without this requirement?
– Attainable: Is this requirement technically feasible within given time and cost?
– Modular: Will a change to this requirement have a big impact on the system? Can this requirement be
easily used and monitored by other programs if needed?
– Restrictive – The requirement should written in such a way as to not limit implementation. Make sure the
requirement states what needs to be done not how.
- 26. © 2011 IBM Corporation
Software and Systems Engineering | Rational
26
Requirement Writing
9: Conjunctions. There should be only one requirement per statement.
– A requirement should not contain “and” or “or”.
– Requirement which contain “and”, “or” or “and/or” probably contain more than one requirements. These
hard to trace and completely verify.
10: Make sure that if a requirement references another document, that it does
so correctly.
– State if reference is information or part of the requirement.
– Make sure references are listed in applicable document section and state what part of reference applies
- 27. © 2011 IBM Corporation
Software and Systems Engineering | Rational
27
Requirement Writing
11: Make sure Acronyms are used correctly.
– Place the acronym in the acronym list in the specification.
– Spell out the complete phrase followed by the acronym in parenthesis the first time used.
– The next time just use the acronym.
– Example: first use: “The SATCOM Antenna Interface Unit (SAIU) shall…”, second use “The SAIU
shall…”
12: Overspecification leads to unfunded requirements, and can add duplicate
requirements.
– The length of a requirement should not be excessive.
- 28. © 2011 IBM Corporation
Software and Systems Engineering | Rational
28
Requirement Writing
13: Use the requirement template
There are four major parts to a requirement:
– Entities –
• Subject of the requirements (noun)
• Object of action (noun)
– Actions – What the subject does, contains imperative (verb)
– Conditions – What must be in place in order for this action to take place
– Constraints– Qualifies the action, performance
The following is the structure of a basic requirement:
[Conditions] [Subject] [Action] [Object] [Constraint]
Example:
When signal x is received [Conditions] , the system [Subject] shall set
[Action] the signal x received bit [Object] within 2 seconds [Constraint].
- 29. © 2011 IBM Corporation
Michelle Specht
Requirements Elicitation
- 30. © 2011 IBM Corporation
Software and Systems Engineering | Rational
30
Requirement Elicitation
The development process starts with understanding the client’s
“business requirements”.
For the success of any project, an agreed upon understanding of the
desired capability is extremely critical.
Requirements elicitation is the process of identifying the sources of
requirements for a new project and obtaining those requirements
from those sources.
The most important outcome is that the people who need to
understand the requirements can do so.
- 31. © 2011 IBM Corporation
Software and Systems Engineering | Rational
31
Requirement Elicitation
There are many ways in which requirements can be gathered, there are
several requirements elicitation techniques available to use
You should gather requirements using whichever method works for you.
Whether you prefer a written document, screen diagrams, prototyping or
use cases
Keep in mind that your choice of techniques will depend on your comfort
level or familiarity, the complexity or nature of your project as well as the
stakeholders you are talking to.
Each requirements elicitation technique has its advantages and
disadvantages and that there is no one technique that works for every
situation.
The following are some popular and recommended techniques for
requirements elicitation:
- 32. © 2011 IBM Corporation
Software and Systems Engineering | Rational
32
Requirement Elicitation
1. Interviews: This technique uses a series of questions to
extract information from the stakeholder, that focus on the
client’s perspective, develops an understanding of the
problem and finally evaluates the effectiveness of the
meeting.
2. Document Review: All effective requirements elicitation
involves some level of document analysis such as business
plans, markets studies, contracts, requests for proposals,
statements of work, existing guidelines, analyses of existing
systems, and procedures. Improved requirements coverage
results from identifying and consulting all likely sources of
requirements.
- 33. © 2011 IBM Corporation
Software and Systems Engineering | Rational
33
Requirement Elicitation
3. Brainstorming: Brainstorming is a powerful
technique because the most creative or effective
ideas often result from combining seemingly
unrelated ideas. Also, this technique encourages
original thinking and the proposal of unusual ideas.
Brainstorming involves both idea generation and idea
reduction. The goal of the former is to identify as
many ideas as possible, while the latter ranks the
ideas into those considered most useful by the group.
4. Use Cases: A use case is a picture of actions that a
system performs by depicting the actions. This should
be accompanied by a textual description and should
not be used in isolation from other requirements
gathering techniques. Use cases and scenarios are
known for facilitating team communication. They
provide a context for the requirements by expressing
the sequence of events and a common language for
the end users and the technical team.
- 34. © 2011 IBM Corporation
Software and Systems Engineering | Rational
34
Requirement Elicitation
5. Requirements Workshops: This technique is considered
very powerful for eliciting requirements because they can
be designed to encourage consensus concerning the
requirements of a particular capability. Other advantages
that are achieved by this technique includes commitment
of participants to the work products and project success,
teamwork, resolution of political issues and reaching
consensus on a host of topics.
6. Prototyping: This technique helps in building a quick and
rough version of the desired system or parts of the system.
This illustrates the capabilities of the system to users and
designers. This technique serves as an excellent means of
communication mechanism for all reviewers in
understanding the interactions with the system. This
sometimes gives an overly optimistic impression of
completion possibilities since an impression is created that
the developers are further along than is actually the case.
Prototypes can be combined very effectively with other
approaches such as JAD and models.
- 35. © 2011 IBM Corporation
Software and Systems Engineering | Rational
35
Requirement Elicitation
7. Storyboards: This technique is a set of drawings depicting a
set of user activities that occur in an existing or envisioned
system or capability. Storyboards may be thought of as forms of
paper prototyping. In this technique, the Customers, Users or
developers start by drawing pictures of the screens, dialogs,
toolbars and other elements they believe the software should
provide. These drawings are evolved by the group till the real
requirements and details are worked out and agreed upon. This
technique is in expensive and eliminates the risks and higher
costs of prototyping.
8 Interfaces Analysis: One of the major
causes of overrun is missing or incorrect
interface. Identifying the external interfaces
early clarifies product scope, aids risk
assessment, reduces product development
costs, and improves customer satisfaction.
The steps of identifying, simplifying,
controlling and monitoring interfaces help
to reduce the risk of problems related to
interfaces.
- 36. © 2011 IBM Corporation
Software and Systems Engineering | Rational
36
Requirement Elicitation
9. Glossary: to use the same language as your client. If the language
is consistent, it greatly lowers the risk of misinterpretation of the
requirements. Problems can develop if we didn’t use the same
terms as the client. To avoid this problem is to include a glossary of
terms and definitions in the requirements document.
10. Modeling: A model is a
representation of reality or level of
abstraction that is intended to
facilitate understanding. They help
eliminate ambiguities and
inconsistencies and are correlated
with the most successful projects.
- 37. © 2011 IBM Corporation
Software and Systems Engineering | Rational
37
Requirement Elicitation
11. Separate the problem and solution space: It is important to keep requirement elicitation
implementation free. You should be working on understanding the problem, not solving it. Not
keeping the requirements elicitation design free can create unnecessary restrictions and your
product
- 38. © 2011 IBM Corporation
Software and Systems Engineering | Rational
38
Requirement Elicitation
12. Validating Requirements: One of the key activities
to determine you have the right set of requirements is
the requirement Validation: Before we accept
requirements from Systems or a customer, we need to
review the requirement set to see the quality of the
requirements. This would let us know what is missing
and what work needs to be done to the requirements.
Can now develop a plan to address requirement needs.
- 39. © 2011 IBM Corporation
Michelle Specht
Using Requirement Management Tools
- 40. © 2011 IBM Corporation
Software and Systems Engineering | Rational
40
Query attributes to find specific properties
– “How many requirements are listed as high risk?”
Use traceability reports for checking dependencies
– Before change is committed
Find “missing” links
– “Which detailed requirements has no relation to a
high-level user requirement?”
Coverage analysis
– “Which higher level requirement has no lower-level
requirement?”
Impact analysis
– “What lower level requirements are affected if a high
level requirement changes?”
Keep traceability
– For each increment, if you develop incrementally with
concurrent phases
– For each variant, if you manage variants and
product lines
The benefits of good requirements engineering tools...
- 41. © 2011 IBM Corporation
Software and Systems Engineering | Rational
41
Rational Requirements Definition and Management Solution
Enabling business & technology experts to build business value
41
Requirements Management
Rational DOORS & Rational RequisitePro
Understand the impact of change as it occurs
and ensure full traceability to
better manage project risk
Search, filter
on attributes
Traceability
between related
artifacts
Impact &
Coverage analysis
Business
Objectives
Business
Processes
Storyboards
Requirements Definition
Rational Requirements Composer
Elicit, capture, elaborate, review and
discuss requirements using a
variety of techniques and notations
Rich text
Documents
Achieve stakeholder
consensus early and often in
the development lifecycle to
reduce rework and improve
time to market
Improve collaboration among
distributed teams to increase
productivity and quality
Insure alignment of business
and IT through linking and
traceability of requirements
artifacts to increase reuse
and ensure effective
software delivery
Use Cases
Prototypes
Visual
Validation
Sketches
- 42. © 2011 IBM Corporation
Software and Systems Engineering | Rational
42
More information
Requirement management and
definition webpage:
Rational RM Solutions
- 43. © 2011 IBM Corporation
Software and Systems Engineering | Rational
43
Rational Publishing Engine: Document automation across
the development lifecycle
Quickly and accurately create the right document for
your development domain at the required time
Access data from a wide range of Rational tools,
including:
DOORS
ClearCase/ClearQuest
Focal Point
System Architect
Rational Quality Manager
RequisitePro
Rhapsody
Rational Requirements Composer
Team Concert
Test Manager
Access data from third party tools via XML and REST
interfaces
Out-of-the-box document templates provided for quick
ROI
- 44. © 2011 IBM Corporation
Software and Systems Engineering | Rational
44
RPE – Can create a document from multiple sources.
This document extracts data from DOORS, ClearQuest and Rhapsody
- 45. © 2011 IBM Corporation
Software and Systems Engineering | Rational
45
Smarter
healthcare
Smarter
electronic
devices
Smarter
defense
systems
Smarter
energy
Smarter
hybrid
technologies
Smarter
automobiles
Smarter Requirements Build Smarter Products
45
Innovation for a smarter planet
- 46. © 2011 IBM Corporation
Software and Systems Engineering | Rational
46
- 47. © 2011 IBM Corporation
Software and Systems Engineering | Rational
47
Systems and Software Engineering Symposiums
- 48. © 2011 IBM Corporation
Software and Systems Engineering | Rational
48
Upcoming symposiums
Landing page for all Symposiums:
http://www.ibm.com/events/systemsengineeringsymposium
- 49. © 2011 IBM Corporation
Software and Systems Engineering | Rational
49
Upcoming symposium
DC Flyer
- 50. © 2011 IBM Corporation
Software and Systems Engineering | Rational
50
© Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied.
IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties
or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs,
or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on
market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, and other IBM products and services are
trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
Learn more at:
IBM Rational software
IBM Rational Software Delivery Platform
Process and portfolio management
Change and release management
Quality management
Architecture management
Rational trial downloads
Leading Innovation Web site
developerWorks Rational
IBM Rational TV
IBM Business Partners
IBM Rational Case Studies