Larry Boldt

1
Thinking Outside the Requirements Management Box
Managing Requirements at the Object
Level Chicago SPIN February 3, 2000
Larry Boldt SVP, Software Services Technology
Builders, Inc. (TBI) larry_at_tbi.com 770.937.7881
2
Topics

• The traditional approach to Requirements
  Management
• The object-oriented approach Why we need to
  think outside the Requirements Management Box
• Getting your organization to think outside the RM
  Box

3
What is a Requirement?

• A Requirement may be many things, including
• A statement of the problem
• A negotiated win condition
• A statement identifying a capability, physical
  characteristic, or a quality factor that bounds a
  product or process need of the proposed solution

4
Requirements Management Involves . . .

• Planning
• Establishing requirement management standards
  and guidelines
• Organizing
• Staffing projects with personnel who understand
  and are charged with their requirement management
  responsibilities
• Directing
• Ensuring that program/project managers lead and
  direct project personnel to follow the
  requirement management standards and process
• Controlling
• Ensuring that a standard change procedure is
  established and followed that allows necessary
  requirement state changes

5
Key Lifecycle Processes
Tests
Tasks Estimates
Requirements
drive the process
Components
Deliverables
6
Who does Requirements Management Today ?

• Environments
• 1. Cost of failure is very high or
  life-threatening
• 2. Complexity is very high
• 3. Regulations require extensive documentation
• 4. Engineering of embedded systems

• Industries
• Military
• Medical
• Avionics
• Telecoms
• Manufacturing
• Embedded Systems
• Financial

7
Who will do Requirements Management Tomorrow?

• Trends
• 1. increasing recognition among development
  teams of the need to mitigate the cost of failing
  to meet requirements
• 2. increasing focus among certain requirements
  management vendors on understanding the needs of
  software developers outside of the traditional
  markets

Giga Information Group
8
Causes of Project/Product Failures

• 1. Failure to meet project or market
  requirements
• 2. Technical complexity
• 3. Inaccurate budgeting or planning
• 4. Design/implementation errors

Giga Information Group
9
The Goals of Most Projects

• 1. On time and within budget
• 2. High level of quality
• 3. Meets requirements

Which one are you willing to sacrifice?
10
Requirement Failures Occurred Because . . .

• 1. Willingness to sacrifice requirements to meet
  date, cost, and bug counts
• (lack of commitment)
• 2. Failure to gather requirements accurately in
  the
• first place
• (lack of a shared form)
• 3. Software drifted away from meeting
  requirements during the development process
• (lack of process)

11
What the Business Needs . . .
What the customer really needs
12
The Requirements Management Challenge
What gets lost in the translation?
13
The Goal of Requirements Management
Common vision among all stakeholders
14
Traditional Inside the RM Box Thinking
Requirements Management
Informal Process Project Focused Document
Creation Translation Interpretation One-time
Usage Manage Documents Limited Change
Notification
15
Why We Need to Change the RM Process
Experiences using Formal Methods for
Requirements Modeling. Easterbrook, et al.
16
What the Experts Have to Say ...

• Ever wonder why there are so many buggy
  e-commerce
• sites? Its a sorry tale of web presence over
  performance.
• The mad dash to create e-commerce sites is
  forcing
• prudent business practices out the window.
• The trend is how fast can you get the site up,
  not did
• you test and test again. Thats why we are seeing
  a
• lot of legal disclaimers on the bottoms of
  sites.
• Its the Ready, Shoot, Aim school of
  development.

17
What if . . .

• The requirements specification were treated as a
  group of integrated, reusable objects instead of
  a static document?
• Requirements could be captured at their source
  instead of being gathered and translated from one
  source to another?
• Requirements were stored in a central repository
  where they could be communicated and collaborated
  on by the entire organization?
• All stakeholders were automatically notified any
  time a requirement changed?

18
Outside the RM Box Thinking
Requirements Management
Enterprise Focused
Integrated Process
Informal Process Project focused Document
Creation Translation Interpretation One-time
Usage Manage Documents Limited Change
Notification
Timely Notification
Manage Objects
Reusability
Source Capture
Document Generation
Impact Analysis
19
Lifecycle of a Requirement Object
Requirement Elicitation
20
Things We Need Answers to . . .
are we doing this task? is this component
supposed to do? will we integrate this? can I
expect this functionality? is this request being
fulfilled?
Why What How When Where
21
Lifecycle Process Relationships
Why? What? How?
Who/ When? If - Then Prove It Manage Change
22
Can Technology Help?

• How do we record and use requirements today?
• Paper
• Verbal agreements
• We could . . .
• Use word documents
• Build databases - Access, Excel, SQL Server,
  Oracle
• The process remains a manual one in all cases!

23
Minimum Technology Requirements

• Team/Collaboration Support
• Locking/Sharing
• Collaboration/Discussion
• Version control/Tracking
• Baselining
• Lifecycle Support
• Dependency/Relationship traceability
• Lifecycle Integration (test, design project
  objects)

• Requirements Capture
• Descriptive text
• Attributes
• Reuse
• External References
• Requirements Publishing
• Individual Standard reports
• Online batch hard-copy generation
• Web publishing

24
Getting Your Organization Out of the Box

• Who is involved in the requirement management
  process?
• At what phases of the lifecycle do you capture
  and document requirements?
• How and where do you document and maintain your
  requirements?
• How do you manage changes to requirements?
• How much time do you spend writing and publishing
  requirements documents?

25
What are the Alternatives?

• Do Nothing
• Keep process manual and labor intensive
• Use word processing files and E-mail as
  documentation
• Hope nothing in the process breaks!
• Do Something
• Develop a strategy to improve the process
• Automate where we can
• Minimize system and user change
• Think Outside the Box
• Develop a new process
• Improve cycle times (make it a goal)
• Partner with the business (provide 2-way feedback
  - goal sharing)
• Centralize the dissemination of project related
  information

26
Other Questions We Need to Answer . . .

• Why do we need requirements management?
• What are the alternatives?
• When should requirements management be used?
• How can we accomplish this?

27
Why do We Need Requirements Management?

• To Visualize the Business
• Document agreement of what the business wants to
  accomplish
• Remove ambiguity
• Enable the Big Picture view of the business
• To Focus Resources
• Right resource/Right application
• Manage customer expectations
• Control project expense
• Doing the right things right the first time

28
When Should Requirements Management be Used?

• Business
• projects needing control over customer-driven
  agreements
• deliverables that customers consider critical
• IT
• all planned, budgeted deliverables
• all development and infrastructure projects
• for budget planning

29
How Can We Accomplish This?

• Pilot the Process
• Define the customer organization
• Recruit key business executive sponsor
• Meet all the requirements and exceed them if
  possible
• Document the experience
• Determine needs and ROI
• Cost avoidance for rework delays

30
Best Practices

• Define requirements as objects
• Make individual owners responsible for
  requirement quality
• Encourage buy-in from both IT and Business at all
  stagesbuild it in
• Derive each successive level of requirements from
  the previous
• Manage change with an iron fist
• Conduct requirement ambiguity reviews

31
Starting Tomorrow . . .

• Guidelines for Writing Quality Requirements
• Write in a style readable by all audiences
• Write requirements in a casual language as
  opposed to a formal language (e.g., computer
  language)
• Keep sentences and paragraphs short
• Avoid ambiguity (multiple meanings/interpretations
  
• Write requirements at a consistent level

32
Starting Tomorrow . . .

• Guidelines for Reviewing Requirements
• Do you understand the requirement?
• - Unambiguous
• - Complete
• - Testable
• - Modifiable
• Is the requirement valid?
• - Correct
• - Necessary
• - Feasible
• Does the set of requirements make sense?
• - Consistent
• - Traceable
• - Prioritized

33
Avoid Ambiguous Terms

• support
• minimize
• maximize
• optimize
• rapid
• user-friendly
• easy
• simple
• often
• usually

• large
• intuitive
• robust
• state-of-the-art
• improve
• efficient
• flexible
• and/or
• etc.

34
Requirements as objects provides ...

• Visibility
• clearer elicitation, analysis and communication
• Reusability
• versioning and baselining of requirements within
  a software project that has multiple releases.
• Testability
• verification and validation on an individual
  level.
• Traceability Replaceability
• tracing from inception to deployment.
  Stakeholders immediately know what components
  need to be changed or replaced.
• Maintainability Security
• Each requirement has its own individual change
  history and level of security.

35
Thinking Outside the Requirements Management Box
Managing Requirements at the Object
Level Chicago SPIN February 3, 2000
Larry Boldt SVP, Software Services Technology
Builders, Inc. (TBI) larry_at_tbi.com 770.937.7881