As a regulatory agency, we need a system to manage compliance data so that we can effectively monitor organizations and ensure public safety.

1. Requirement Excellence
Framework™
Requirements Development
www.EnfocusSolutions.com

2. Requirements Development
1
Related Rules
Scope
Statement
Functional
Requirement
Supplemental
Requirement
Project
Stakeholder
Feature
Impact
Process
Impact
Stakeholder Need
User Story
Use Case
Project Stakeholders are identified
during Stakeholder Analysis
and used to define stakeholder
needs and user stories. Project
stakeholders are also used as actors
in Use Cases.
Process Impacts are
identified during Process
Analysis and used to
define scope statements.
Impacts on products and
services are identified during
Project Scope and are used to
create scope statements.
Scope Statements are defined in the Project Scope activity and
used to elicit needs and specify requirements.
Related Rules are identified
during Specification and
linked to a requirement.
Functional Requirements
are created during
Specification..
Stakeholder Needs are
identified during Elicitation
through a variety of
elicitation techniques such as
web
forms, interviews, observatio
ns and group discussion.
User Stories are a special type
of need which are created
during Elicitation.
Supplemental Requirements
are created during
Specification..
Use Cases are
developed by the analyst
during Analysis to gain a
better understanding of
the sequence of events
and user involvement.
Note that Requirements Development is an iterative and incremental activity. Generally
Elicitation, Analysis, Specification, and Validation go on concurrently.

3. Elicitation is the process of gathering and documenting needs from
stakeholders, identifying other requirements sources, and applying
techniques specified in the RMP to gather the information and
document the needs
• Stakeholder Needs
• Document Review
• User Stories
• Use Cases
Analysis is the process of analyzing the data gathered during
elicitation, resolving conflicts, analyzing business rules, documenting
assumptions, constraints, and dependencies, and working with
stakeholders to establish initial priorities.
• Stakeholder Needs
Analysis
• Document Review
Analysis
• Business Rules Analysis
Specification is the process of defining functional and supplemental
text based requirements and supporting them with various
visualization techniques such as process models, UML
diagrams, wireframes, white boarding, etc.
• Functional requirements
• Supplemental
requirements
• Visualizations
Validation is the process of reviewing the requirement specifications
and associated visualizations with the stakeholders for quality
characteristics such as
completeness, correctness, clarity, practicality, value, etc.
• Validated requirement
bundle
Requirements Development
2
Elicitation
Analysis
Specification
Validation
Requirements development is the process of studying stakeholder needs to arrive at as set of complete and
prioritized requirements that address strategy, people, process, and technology issues related to the project.

4. Strategy, People, Process, and
Technology
3
Strategy People Process Technology
• Business Objectives
• Project Vision
• Project Scope
• Project Constraints
• Stakeholder Analysis • Process Analysis • Technical Constraints
• Organizational
Change Needs
• Business Process
Needs
• Related Business
Rules
• Use Cases
• User Stories
• Organizational
Change and Training
Requirements
• Business Process
Requirements
• Functional
Requirements
• Supplemental
Requirements

5. Elicitation
• The optimal method for eliciting needs is for stakeholders to document their own
needs in their own words using the Stakeholder Portal™. The Business Analyst can
assist the Stakeholders by providing examples and guidance.
• The Stakeholder Portal™ may also be used to capture the needs of a group in the
event that a workshop or series of workshops is used.
• In the event that workshops or interview are used, analysts need to recognize that
customers will not be able to express all their needs in a single workshop or
interview.
• In addition to system needs, business process and organizational change needs
should also be captured. Failure to do so will most likely result in suboptimal
solution.
• Elicitation requires multiple cycles of refinement, clarifications, and adjustment as
participants move from high level concepts to specific details perhaps through a
series of releases or iterations.
• Related documents, notes, or graphics should be gathered and stored as
attachments for further reference. These attachments can be linked to needs in
the Stakeholder Portal.™
4

6. Elicitation Techniques
5
Documentation
Review
Review relevant documents
such as regulations, internal
audit reports
Stakeholder Portal
Stakeholders record their
needs directly using the
Stakeholder Portal
Use Cases
Business Analysts create use
cases for major activities
and review with
Stakeholders
Workshops
Sessions are held to identify
and document user needs
Observation
Business Analysts document
needs by observing work
performed
Interviews
Key stakeholders are
interviewed to ascertain
their needs
Stakeholder Analysis
Needs are identified when
conducting the Stakeholder
Analysis
Brainstorming
Needs are captured in a
brainstorming session using
a Mind Map.
Business Process
Analysis
Needs are identified when
defining the “To Be”
business process model

7. Elicitation Documentation
Confidential - Not for External Distribution 6
Stakeholder Needs User Stories Use Cases
Needs are documented in
words the stakeholder
understands using
predefined patterns included
in the Stakeholder Portal™
• General Capability
• Reports and Queries
• Compliance
• Security and Controls
• Performance
• Safety
• Operating Environment
• Documentation
• User Interface
• Organizational Change
• Business Process Changes
Needs are documented
using a User Story based on
the pattern below
As a type of user
I need to do this activity
So that I can achieve this
benefit
Business Analyst define use
cases to document the work
of the stakeholder and how
he interacts with the system.
A use case is a description of
steps or actions between a
user (or "actor") and a
software system which
allows the user to perform a
meaningful task. The user or
actor might be a person or
something more abstract,
such as an external software
system or manual process.
Attachments
Related meeting notes, documents, graphics, etc. should be gathered and linked to
the artifacts above.

8. Standish Group Research
What factors cause projects to
become challenged?
1. Lack of User Input
2. Incomplete Requirements &
Specifications
3. Changing Requirements &
Specifications
Why are projects impaired and
ultimately cancelled?
1. Incomplete Requirements
2. Lack of User Involvement
3. Lack of Resources
4. Unrealistic Expectations
5. Lack of Executive Support
6. Changing Requirements &
Specifications
What is needed to achieve project
success?
1. User Involvement
2. Executive Management Support
3. Clear Statement of Requirements
4. Proper Planning
5. Realistic Expectations
6. Smaller Project Milestones
7. Competent Staff
8. Ownership
9. Clear Vision & Objectives
10. Hard-Working, Focused Staff
7
Source: Standish Chaos Report
The Requirement Excellence Framework fully or
partially addresses most of these issues. Good
requirements and user participation will have a
major impact on the success of projects.

9. Requirements Elicitation Risks
• Insufficient user involvement leads to unacceptable products
• Creeping user requirements contribute to overruns and
degrade product quality
• Ambiguous requirements lead to ill-spent time and rework
• Gold-plating by developers and users adds unnecessary
features
• Minimal specifications lead to missing key requirements
• Overlooking the needs of certain user classes leads to
dissatisfied customers
• Incompletely defined requirements make accurate project
planning and tracking impossible
8

10. Requirements Planning Activities
Documenting the Project Vision
• Gaining an understanding of the business strategy and why the project is
being undertaken
Defining Business Objectives
• Defining clear measurable business objectives
Business Process Analysis
• Identifying what business processes will be impacted
• Gaining a full understanding of how the business process will work after
the project has been implemented
• Determining how the new or modified software will support the business
process
Project Scope Definition
Stakeholder Analysis
• Identifying the expected Stakeholders and user classes for the product
9

11. Requirements Development Tasks
Elicitation
• Eliciting needs from individuals who represent each Stakeholder
Analysis
• Analyzing the information received from users
• Understanding actual user tasks and objectives
• Partitioning system-level requirements into major subsystems.
• Understanding the relative importance of quality attributes
• Negotiating implementation priorities
Specification
• Translating the collected user needs into written specifications and models
• Reviewing the requirements specifications Understanding the relative importance
of quality attributes
• Negotiating implementation priorities
• Reviewing the requirements specifications
Validation
10

12. Requirements Management Activities
• Defining the requirements baseline
• Reviewing proposed requirements
• Incorporating approved requirements changes into the
project in a controlled way
• Keeping projects plans current with the requirements
• Negotiating new commitments based on the estimated
impact of changed requirements
• Tracing individual requirements to their corresponding
designs, source code, and test cases
• Tracking requirements status and change activity
throughout the project.
11

13. Stakeholder Needs
12
Project Scope
Record
• General Capability
• Reports and Queries
• Compliance
• Security and Controls
• Performance
• Safety
• Operating Environment
• Documentation
• User Interface
• Organizational Change
• Business Process Changes
Stakeholder Needs
Patterns
Stakeholder
Profile
• Stakeholder Needs are
captured from the point of
view of a stakeholder
• Stakeholder needs are
organized by Project Scope
Records
• Stakeholder needs are
captured using predefined
patterns

14. User Stories
• A user story is a short description of customer’s need. User
Stories are commonly used in agile software methodologies
and frameworks such as Extreme Programming or Scrum as a
way of gathering requirements.
• Whenever possible, users should write their own stories;
otherwise they can be written by business analyst on behalf of
the user.
• User stories are generally expressed using the template below.
13
“As a <specific user/
/role>” I what <desired feature/issue that needs to be
solved>, so that <benefit from implementing the
feature>” + Test Cases (Acceptance Criteria)

15. Use Cases
What is a use case?
• A use case is a description of how users will perform tasks on your System.
• A use case includes two main parts:
– the steps a user will take to accomplish a particular task on your site
– the way the Web site should respond to a user's actions
• A use case begins with a user's goal and ends when that goal is fulfilled.
What does a use case describe?
• A use case describes a sequence of interactions between a user and a
system, without specifying the user interface.
• Each use case captures:
– The actor (who is using the System?)
– The interaction (what does the user want to do?)
– The goal (what is the user's goal?)
14

16. User Stories
15
• Independent
• Negotiable
• Valuable
• Estimable
• Sized Correctly
• Testable
User stories should be written using INVEST.

17. Other Sources of Requirements
• Existing Process Improvements
– Help Desk trouble tickets
– Trainers and consultants
– Help desk and support team
– Customer suggestions and complaints
– Internal Audit Reports
• Process Improvement
– Process Benchmarking
– Six Sigma Studies
• Competition
– Competitive products
– Analyst Reports
• Other
16

18. Analysis
Analysis is the process of analyzing the data gathered
during elicitation, resolving conflicts, analyzing business
rules, documenting assumptions, constraints, and
dependencies, and working with stakeholders to establish
initial priorities.
• Analysis is not a linear process; it is done concurrently
with the elicitation. Business analysts continually monitor
needs from stakeholders to ensure understanding and to
work with stakeholders that have difficulty in expressing
their needs.
• Based on the business process analysis, business analyst
identify and document business rules that will affect the
system.
17

19. Stakeholder Needs Analysis
• Stakeholder needs are analyzed by the requirements
analyst using the requirements analysis dashboard
• The needs are tagged in variety ways depending on
organizational requirements.
• Tags can be used for
– Return on investment
– Must Have, Nice to Have
– High, Medium and Low Priorities
– Architectural category
18

20. Business Rules Analysis
• Business Rules Analysis is the process of determining
what business rules apply to the requirements.
• The business rules are maintained by rule book in a
knowledgebase
• Applicable business rules are linked to requirements
during analysis and specification
19

21. Business Process Analysis
• Review the “As Is” and “To Be” business analysis and
identify actions that need to be done to accomplish
the business objectives, achieve the project
vision, and deliver the project scope.
20

22. Specification
Specification is the process of defining functional and
supplemental text based requirements and supporting
them with various visualization techniques such as
process models, UML diagrams, wireframes, white
boarding, etc.
Confidential - Not for External Distribution 21

23. How Much Detail do You Need?
Confidential - Not for External Distribution 22
• Extensive customer Involvement
• Developers have considerable
domain
• Experience
• Precedents are available
• Package solution will be used
• Outsourced development
• Team is geographically dispersed
• Testing will be based on requirements
• Accurate estimates are needed
• Requirements traceability is needed
Less Detail More Detail
• As usual in software development, the answer to this question is, “It depends.”
• The central question to consider when deciding how detailed to make the requirements is:
Who do you want to have making decisions about requirements details and when?
• If you’re willing to defer many of the ultimate decisions about product capabilities and
characteristics to the developers, then you don’t need to include as much detail in the
requirements documentation.
• However, if you want to ensure that you get exactly what you expect, you need more
comprehensive specifications.
• Don’t expect that even the best written requirements specification can – or should –
replace human dialogue.

24. Requirements vs. Design
Confidential - Not for External Distribution 23
Why undertake the project?
(business objectives)
What the user will be able to do with the product?
(Stakeholder Needs, Use Cases, User Stories)
What the developer builds?
(Functional and Supplemental Requirements)
Systems components and how they fit together?
(System Architecture, Component Architecture, UI Architecture)
Systems components and how they fit together?
(Class Diagram, Database Design, User Interface Design)
How the components will be implemented?
(Algorithms, UI Controls)
Decreasing
Abstraction

25. Writing Clear Requirements
Write in Active Voice
With active voice, the reader doesn’t have to deduce what entity is doing what. It’s
easier for readers to understand explicit and precisely stated requirements that are
written in active voice. Fewer assumptions are needed to interpret the requirement.
Example:
• Passive (weak): When the output state changes, it is logged in the event log.
• Active (strong): When the output state changes, the system shall record the new
state in the event log.
Avoid Ambiguity
• An ambiguous requirement is one that the reader can interpret in more than one
way, or one that different readers can interpret in multiple ways.
Don’t Design the System
• If we supply too much detail, we start to design the system prematurely. Danger
signs include: name of components, materials, software objects/procedures,
database fields,
Confidential - Not for External Distribution 24

26. Writing Clear Requirements
Avoid Negation
• Before: All users with three or more accounts
should not be migrated.
• After: The system shall migrate only users
having fewer than three accounts.
• Before: The security module will not allow
access by users who do not have a valid
userid and password.
• After: The security module shall only allow
access by users who have a valid userid and
password.
Watch for Omissions
• Before: The system shall display the user’s
defined bookmarks in a collapsible
hierarchical tree structure.
• After: The system shall display the user’s
defined bookmarks in a collapsible and
expandable hierarchical tree structure.
Be Careful of Boundary Values
• Before: 1. If the amount of the cash refund is
less than $50, the system shall open the cash
register drawer.
If the amount of the cash refund is more
than $50 and the user is not a supervisor, the
system shall display a message: “Call a
supervisor for this transaction.”
• After: 1. If the amount of the cash refund is
less than or equal to $50, the system shall
open the cash register drawer.
If the amount of the cash refund is more
than $50 and the user is not a supervisor, the
system shall display a message: “Call a
supervisor for this transaction.”
25

27. Writing Clear Requirements
Watch synonyms and Near Synonyms
• use terms consistently
• define terms in a glossary
Be Careful of Similar Sounding Words
• “Special Day caller tunes (default) will take
priority over all configured individual caller
settings that a customer has selected.
However, if an individual has been assigned a
Special Day caller tune for the same
date, this will overwrite the Special Day caller
tune.”
Pronouns
• make the antecedents crystal clear
Be Careful with Vague Adverbs
• Provide a reasonably predictable end-user
experience.
• Offer significantly better download times.
• Optimize upload and download to perform
quickly.
• Downloading should complete in
approximately 15 minutes.
• Exposing information appropriately…
• Generally incurs a “per unit” cost…
• To enable remedial action to be initiated in a
timely manner…
• …as expediently as possible…
• Occasionally (not very frequently) there will
be an error condition…
• others:
easily, ideally, instantaneously, normally, opti
onally, periodically, rapidly, typically, usually
26

28. Writing Clear Requirements
i.e. and e.g.
• i.e. = “that is”; e.g. = “for example”
• “The system shall use single-letter
color codes, i.e., R for red, G for
green, and B for blue.”
• better to use English
Do not Use Vague Terms
• user-
friendly, modern, robust, efficient, ve
rsatile, flexible
• efficient, flexible, robust, high-
performance
• seamless, transparent, graceful
• improved, state-of-the-art, superior
• rapid, easy, simple, intuitive,
• minimize, maximize, optimize
• few, several, some, many, approximat
ely
• sufficient, adequate, at least
• reasonable, where appropriate, to
the extent possible,
• if necessary, optionally
• etc., including, and/or
• as possible
27

29. Writing Clear Requirements
Don’t Express Possibilities
• May, might, should, ought, could,
perhaps, probably
Avoid Wishful Thinking
• 100% reliable
• Safe
• Handle all unexpected failures
• Please all users
• Run on all platforms
• Never fail
Don’t Speculate
• Usually
• Generally
• Often
• Normally
• Typically
Avoid Conjunctions
– And, or, with, also
Don’t ramble
• Example- Provided that the designated
input signals from the specified devices
are received in the correct order where
the system is able to differentiate the
designators, the output signal shall
comply with the required framework of
section 3.1.5 to indicate desired input
state.
28

30. Anatomy of a Good Requirement
Confidential - Not for External Distribution 29
User Category Who benefits from the
requirement
The Call Center operator
Expected Result Desirable state for the
user to reach
shall be able to see the
customer record
Mechanism to Test Mechanism to allow a
test to be written against
the requirement.
within 2 seconds from
the time the call is
received.

31. Quality Attributes for Requirements
• Requirement Bundles
– Complete - nothing is missing; nothing should say “to be determined”
– Consistent requirements should not conflict with other requirements
• Individual Requirements
– Correct - accurately states a customer or external need
– Clear - has only one possible meaning
– Feasible - can be implemented within known constraints
– Modifiable - can be easily changed, with history, when necessary
– Necessary - documents something customers really need
– Prioritized - ranked as to importance of inclusion in product
– Traceable - can be linked to system requirements, and to
designs, code, and tests
– Verifiable - correct implementation can be determined by
testing, inspection, analysis, or demonstration
Confidential - Not for External Distribution 30

32. Prioritization Scale
• Prioritization scale is based on Stephen R. Covey, The
7 Habits of Highly Effective People, Simon &
Schuster, 1989
31
Urgent Not Urgent
Important
High Priority
Must be included in the next
release
Medium Priority
Must be included but cant
wait for later release
Not
Important
Low Value
Do not add sufficient value for
to include in the project
Low Priority
Nice to have if you have the
budget to include

33. Requirement Visualization
Requirement Visualization
Whiteboarding
Storyboards UML Models
Photos and
Videos
Business
Process
Diagrams
Illustrated
Concept
Diagrams
Enfocus Requirement Suite integrates with many requirement visualization tools and technologies. With
the Suite, output from these tools can be related to requirements and use cases, as well as other
artifacts. Requirement Coach provides guidance for integrating these tools.
Wireframes
32

34. Supplemental Requirements
• Performance
• Archival and Storage
• Security and Controls
• Usability
• Look and Feel
• Access Control
• Training
• Business Process and Workflow
• Infrastructure
• Documentation
• Business Continuity
• System Connectivity
• Interface Transaction
Confidential - Not for External Distribution 33