Requirement Excellence Framework™

Requirements Development

www.EnfocusSolutions.com

2

Requirements Development

Related Rules

ScopeStatement

FunctionalRequirement

SupplementalRequirement

ProjectStakeholder

FeatureImpact

Process Impact

Stakeholder Need

User Story

Use Case

Project Stakeholders are identified during Stakeholder Analysisand 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, observations 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

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

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.™

6

Elicitation Techniques

Documentation Review

Review relevant documents such as regulations, internal

audit reports

Stakeholder PortalStakeholders record their needs directly using the

Stakeholder Portal

Use CasesBusiness Analysts create use cases for major activities and

review with Stakeholders

WorkshopsSessions are held to identify and document user needs

ObservationBusiness Analysts document

needs by observing work performed

InterviewsKey stakeholders are

interviewed to ascertain their needs

Stakeholder AnalysisNeeds are identified when

conducting the Stakeholder Analysis

BrainstormingNeeds are captured in a

brainstorming session using a Mind Map.

Business Process Analysis

Needs are identified when defining the “To Be”

business process model

Confidential - Not for External Distribution

7

Elicitation DocumentationStakeholder 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.

AttachmentsRelated meeting notes, documents, graphics, etc. should be gathered and linked tothe 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?

4. Incomplete Requirements 5. Lack of User Involvement 6. Lack of Resources 7. Unrealistic Expectations 8. Lack of Executive Support 9. Changing Requirements & Specifications

What is needed to achieve project success?

1. User Involvement 2. Executive Management Support3. 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

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

10

Requirements Planning Activities

Documenting the Project Vision• Gaining an understanding of the business strategy and why the project is

being undertakenDefining Business Objectives• Defining clear measurable business objectivesBusiness 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

processProject Scope DefinitionStakeholder Analysis• Identifying the expected Stakeholders and user classes for the product

11

Requirements Development Tasks

Elicitation• Eliciting needs from individuals who represent each StakeholderAnalysis• 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 prioritiesSpecification• 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 specificationsValidation

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.

13

Stakeholder Needs

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 NeedsPatterns

StakeholderProfile

• 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.

“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?)

16

User Stories

• 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

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.

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

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

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.

Confidential - Not for External Distribution

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

23

How Much Detail do You Need?

• 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.

Confidential - Not for External Distribution

24

Requirements vs. DesignWhy 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)

DecreasingAbstraction

Confidential - Not for External Distribution

25

Writing Clear Requirements

Write in Active VoiceWith 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,

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.”

27

Writing Clear Requirements

Watch synonyms and Near Synonyms• use terms consistently• define terms in a glossaryBe 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, optionally, periodically, rapidly, typically, usually

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,

versatile, 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, approximately• sufficient, adequate, at least• reasonable, where appropriate, to the

extent possible,• if necessary, optionally• etc., including, and/or• as possible

29

Writing Clear Requirements

Don’t Express Possibilities• May, might, should, ought, could,

perhaps, probablyAvoid Wishful Thinking• 100% reliable• Safe• Handle all unexpected failures• Please all users• Run on all platforms• Never failDon’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.

Confidential - Not for External Distribution

30

Anatomy of a Good Requirement

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.

Confidential - Not for External Distribution

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

32

Prioritization Scale

• Prioritization scale is based on Stephen R. Covey, The 7 Habits of Highly Effective People, Simon & Schuster, 1989

Urgent Not Urgent

ImportantHigh Priority

Must be included in the next release

Medium PriorityMust be included but cant

wait for later release

Not Important

Low ValueDo not add sufficient value for

to include in the project

Low PriorityNice to have if you have the

budget to include

33

Requirement Visualization

Requirement Visualization

WhiteboardingStoryboards 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

Confidential - Not for External Distribution

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