Requirements Management Practices: The 'Essence'

By: Betty Luedke

Abstract: Based on requirements management (RM) concepts, strategies, and best practices, design your own RM Practices -- The 'Essence' that focuses on bringing real value to the system development process.

Betty Luedke is an accomplished project manager, requirements analyst, and facilitator with 22 years experience in the software development industry. Her broad experience in the analysis, design, and development of object-oriented, relational, and hierarchical data systems for consumer finance, engineering, and medical functions has enabled her to effectively keep the user foremost when applying requirements management (RM) best practices in real product development situations. Betty is a principal consultant for Borland where she: instructs/mentors on CaliberRM and RM processes and techniques; is certified to teach the Karl Wiegers' course, "In Search of Excellent Requirements"; develops requirement management and change management processes; conducts process gap analysis making recommendations for improvements; and, develops RM implementation strategies and mentors client implementation personnel.

Before joining Borland, Betty was a senior systems consultant for The Associates providing team management for project development/business analysis, a senior data architect for Burlington Northern Railroad providing data analysis/database implementation, and a computer systems specialist for Computer Sciences Corporation (CSC) providing enterprise functional/data analysis. Betty holds a Bachelor of Science degree in Mathematics/Education from Florida State University in Tallahassee, Florida with additional coursework in Computer Science.

betty.luedke@borland.com

Requirements Management Practices...The 'Essence'

Betty Luedke - Borland Software Corporation

 


 

Introduction

Defining Requirements for a RM Practice

Process

People

Technology

Designing a RM Practices Document

The 'Essence'

RM Strategies

RM Tasks

System Development Roles

RM Task/Role Participation

RM Techniques

Developing Requirements

Managing Requirements

The 'Detail'

Requirement Type Definitions

Requirement Trace Strategy

Requirement Baseline Strategy

Requirement Versioning

RM Task Descriptions

Role Definitions

Artifact Overview

Decision Matrices

Requirement Information Structure

Change Control Process

Request For Change States

Summary

 


 

Introduction

This paper provides an approach to designing and developing a document to describe your organization's Requirements Management (RM) Practice.  It should be understood that having a meticulously crafted RM process will not necessarily entice your organization to follow it.  First and foremost, whatever guidance is provided to your organization needs to be embraceable and aligned with RM best practices.

Defining Requirements for a RM Practice

There are three very important considerations to keep in mind if we want to successfully implement a RM practice.  These considerations are PROCESS, PEOPLE and TECHNOLOGY.

Our goal is to be effective and  efficient not only in documenting the RM process, but also it is to determine who does what and what tool/technique to should be used.  A basic but driving insight is that PROCESS and PEOPLE make an effort effective, and TECHNOLOGY at best can make an effort efficient.   With this in mind, we need to do all three because if we focus on:

  • Just TECHNOLOGY.............we become very efficient about being ineffective!
  • Just PROCESS-PEOPLE.......we become very effective about being inefficient!

Focusing PROCESS, PEOPLE and TECHNOLOGY at the same time is the key to  being effective and efficient!

So, what do we really need to do!

The PROCESS-PEOPLE-TECHNOLOGY diagram below provides some insights about what we need to our arms around.

Process

From a PROCESS perspective, we must know about RM strategies and the tasks for not only the RM process but for the closely related change management process.  In addition, deliverables need to be identified that support and are consistent with our RM strategies/process.  You will see examples of many of the items as we explore designing a RM practice document.

 People

From a PEOPLE perspective, we must identify/define system development roles because each of these roles is either the source of requirements, the person(s) responsible for eliciting/analyzing the requirements or the consumer of the requirements for designing, coding or testing purposes.  To successfully execute a RM process we will need to employ techniques.  It is very helpful to identify favored techniques and demonstrate how they work together to facilitate a common understanding of the requirements across all roles.

 Technology

From a TECHNOLOGY perspective, we must identify the tool of choice.  Keep in mind, the tool of choice can be paper, MSWord, Excel, database or a requirements management repository, such as CaliberRM.  Once a tool is chosen, then tool procedures should follow providing guidance for executing the RM process with the given tool(s).

 

Designing a RM Practices Document

Designing a RM practices document can be a daunting task for the author and an even more daunting task for the reader.  Is it not a shame if after all that work the potential users of the RM process do not embrace all this good advice?  One reason might be that the sheer volume of the RM process document may make most run the other way.  As we have already seen, there is a lot of information to convey.  How can these important concepts and guidance be presented so that the reader says, "Yes, I understand...that's what we need to do!"?

The first thought might be to make the RM practices lightweight, meaning not too many words or directives.  But then, one often gets the comment, "Well, what do you mean by ____?"  Writing it all down would lead to a 'not so lightweight' RM practices.  What to do?!?

Consider this:

  • All PROCESS, PEOPLE and TECHNOLOGY information mentioned thus far is important.
  • Users of the RM practices will be from different areas of your organization, will be at different levels of understanding, will have different tolerances for detail, will have different 'needs to know',...
  • Continuing with the status quo approach is not an option!

Now, consider that we might be able to address most of these challenges in how we present this information.  Let us make it:

  • Possible to glean the 'essence' without a huge investment of time
  • Possible to find the detail when detail is needed 
  • Possible for anyone (from an executive to a customer to an analyst to a developer to a ...) to embrace the RM concepts/practices, which can make the difference between a successful system development effort and one that fails.

To this end, it is recommended that you:

  • Use diagrams and charts to capture this 'essence' of the RM concepts/process/practices
  • 'Glue' these key references together with a few words of explanation
  •  Provide detail where it is needed in a concisely stated appendix that is referenced in the 'essence'.

The following examples will give you a feel for the 'building blocks' for Requirements Management Practices...The 'Essence'.

 

The 'Essence'

The following sections are focused on the 'essence' of a RM practice which is aligned with RM best practices:

RM Strategies

Requirements management best practices include strategies for:

  • Requirement types1             Requirement types categorize requirements

  • Requirement traces            Requirement traces help:

'        Manage impact of change

'        Ensure completeness

'        Provide justification

  • Requirement baselines     Requirement baselines represent agreements

 

The <company/organization> Requirements Roadmap below illustrates:

  • Requirement types (Requirement Type Strategy)

  • Predictable relationships between requirements types (Requirement Trace Strategy)

  • Directive to have 'early and often' agreements (Requirement Baseline Strategy)

 

 

RM Tasks

Requirement activity is prevalent during the PLANNING/ANALYSIS and CONSTRUCTION phases.  The chart below indicates requirement-related tasks within the phase of the system development life cycle.  

 

RM Task List

 

As we progress through the system development life cycle, we move from determining WHY we are doing a project to discovering WHAT we must build to deciding HOW to build it.  Each RM Task is an action that focuses on one of the following:

  • Defining IT
  • Designing IT...Building IT
  • Proving IT
  • Managing IT

While the listing of requirement-related tasks above maps each task to a system development phase, the diagram below better illustrates:

'        The iterative nature of some groupings of tasks

'        The fact that some of these tasks can/should be done in parallel

'        That all of these tasks are focused on some aspect(s) of effective requirements management

 

RM Task Diagram

 

It is also important to understand that a team may have multiple focuses at any one time as illustrated in the chart below.

 

System Development Roles

The roles described below encompass the responsibilities of the system development process.  It is important to identify system development roles.  These are the hats worn during the system development life cycle.  In turn, roles can be mapped to the current organizational titles to provide job descriptions.  Once defined, roles tend to be stable where organizational structures are not.  Each role has at least one of the following as a primary focus:

1.      Manage project effort

2.      Provide requirements

3.      Analyze requirements

4.      Design system/tests to address requirements

5.      Develop system/tests based on approved design

6.      Prove system meets requirements

7.      Guide development for the enterprise

The chart below identifies system development roles and their primary focus:

 

 

RM Task/Role Participation

For any process to be successful, the people executing each task must understand what is expected.  It is not enough to indicate involvement but divulge what the participation should be.  As you can see in the legend below, participation can vary from being aware to reviewing/approving.

<Fill in the chart below for your organization.>

K          Provides leadership as key participant

P          Participates in a secondary, non-lead role

blank    No participation required for this task

A         Should be aware of the results

V         Should informally validate the output and provide feedback

I          Required as an off-line resource to provide input, answer questions,...

R        Review and approve the results of the task

 

RM Techniques

There are numerous techniques to assist with requirements elicitation/analysis tasks.  The ones highlighted below are inter-related and keep the focus on the users needs:

'   Context Diagram                      A context diagram is a model which depicts the interaction with the system.  Roles (human and non-human) become evident as well as their interactions.  The purpose of this diagram is to see the vision in context and to maintain a focus on the interactions the system must satisfy.

'   Use Case Diagram                    A use case diagram is a model that depicts what tasks each role performs.

'   Use Case Analysis                    Use case analysis is a word model which articulates the sequence of steps for a user task.  The user task which names the use case is a user requirement and each step of the user task (step in the use case) is a functional requirement.

Below are examples of these techniques:

Context Diagram                                                                   User Case Diagram

 

 

Use Case Analysis   

 

Developing Requirements

To develop requirements for a system involves:

'        Elicitation

'        Analysis

'        Specification

'        Verification/Validation

 Each of the above activities will be explored further, but the following are good practices to follow:

Requirement  Strategies/ Process

4   Adopt strategies for requirement types, requirement traces and requirement baselines

4   Adopt a process for developing and managing requirements

4   Adopt requirement information structure

 Elicitation

4   Write project vision and scope

4   Define requirements development process

4   Identify user classes and characteristics

4   Select knowledgeable, empowered, credible business representatives

4   Establish focus groups

4   Identify use tasks and explore each using the use case technique

4   Hold collaborative requirements elicitation workshops

4   Analyze user workflow

4   Define non-functional requirements (quality attributes) and business rules

4   Examine problem reports

4   Reuse requirements across projects

 Analysis

4   Allocate requirements to system components

4   Decompose user requirements into functional requirements

4   Draw a context diagram

4   Create user interface prototypes

4   Analyze requirements feasibility

4   Model the requirements

4   Create a data dictionary 

Specification

4   Adopt a requirements specification template

4   Identify the source of each requirement

4   Uniquely label each requirement

4   Record non-functional requirements and business rules

4   Create requirements traceability matrix

Validation

4   Inspect requirements guided by a requirements quality checklist

4   Write test cases from requirements

4   Write a user manual

4   Define acceptance criteria

4   Evaluate prototypes

 

Eliciting and Analyzing Requirements

To effectively elicit and analyze requirements for a system, it is important to follow the established:

'        Requirements strategies for:

o       Requirement types

o       Requirement traces

o       Requirement baselines

'        Requirements process for developing and management of requirements

In addition, participants need to be identified who are knowledgeable, empowered and credible with peers.

 Each projects vision and scope will determine not only the business requirements, but will be the guiding criteria for all other requirements (user, functional, non-functional, business rules, data).  Appropriate use of techniques (context diagram, use case diagram, use case, prototype, data model, data dictionary,...) will help define requirements that are understandable, correct and consistent.

 

Documenting Requirements

The goal of documenting requirements is to clearly articulate what is needed so that those designing/developing/testing can successfully complete their tasks.  Of course, requirement types help us define what is needed.

 

Requirement Type

Tells us...

Business Requirement

a goal/strategy that is to be accomplished

User Requirement

a task that the user must be able to do to accomplish the business goal

Functional Requirement

a conversation/system feature that the system must be able to do to help the user do a task necessary for accomplishing a business goal

Non-functional Requirement

a quality attribute the system must have

Business Rule

a policy/regulation/standard that the system must follow

Data Requirement

about information that is needed by the system to perform its functions

Constraint

a limitation that is imposed on the system

 Each requirement type has certain information that should be captured but the following minimum information should be captured for requirements of any type:

'        Requirement Identifier

'        Requirement Version Number

'        Requirement Type

'        Requirement Name

'        Requirement Description

'        Requirement Change History

'        Requirement Status

'        Requirement Priority

'        Requirement Owner

'        Requirement Trace Information

 

In addition for the analysis of a user task (user requirement), the following information is needed:

'        Actors

'        Pre-conditions

'        Post-conditions

'        Flow of Events

'        Alternative Courses

'        Exceptions

When a set of requirements is collected in a document, for whatever reason, each requirements needs to be identified by at least:

'        Requirement Identifier

'        Requirement Version Number

Any requirements document should be kept under version control remembering that there is a version number for the requirements document (collection of requirements) and an identifier and a version number for each requirement.  When a requirements document is used to baseline a set of requirements, it will be important to follow a naming convention.

 

Reviewing Requirements

Once a set of requirements has been elicited and analyzed, these requirements should be validated to ensure quality.  The characteristics of a quality requirement2 are:

Characteristics Of An Excellent Requirement

Unambiguous

Clearly states one possible meaning.

Complete

Nothing is missingno etc., TBD,; include exception conditions.

Verifiable

Correct implementation can be verified by testing, review, analysis, demonstration,

Consistent

No conflicting requirements.

Traceable

Linked to the voice of the customer as well as to design, test cases. code,

Modifiable

Can be easily changed, with history, when necessary.

Correct

Accurately states a customer or external need

Necessary

Documents something customers really need

Prioritized

Ranked as to importance of inclusion in product

Feasible

Can be implemented within known constraints

Requirement reviews range from informal to formal inspections.  The key is, however, that they be done early and often so as to minimize the surprise of the XYZ syndrome where the customer said X, the customer meant Y, the requirements analyst heard Z.  The more formal reviews should:

'        Be conducted by a skilled facilitator

'        Have a stated goal

'        Involve the appropriate participants who are prepared

'        Include follow-up activities to bring closure to the inspection (possibly another review of all or part of the requirement set)

The attitude of the participants has a lot to do with how effective the outcome is.  Since the purpose of a review is not to be critical, it is important to state that we are looking to improve the quality requirements so that the product built on this understanding has a half a chance of meeting the customers needs.

Another attitude that gets in the way of quality is the idea that there only needs to be one review of requirements.  If this were true, then we would have to elicit, analyze and specify all requirements before validating the entire set.  Our approach actually encourages the discovery of requirements and offers the possibility of designing/building one part of the system while the requirements for another part are still being developed.

A review of requirements can be conducted in a number of ways, but it is important that it is a reasonable activity.  Early in the system development process we stated/agreed to the business goals for this project.  The common understanding of these business requirements continues as the key to a successful project.  As other types of requirements emerge to support these business requirements, it is no less important to maintain a common understanding.  Requirement reviews provide a way to establish a shared vision of WHAT the system must do, but the effectiveness of a review has as much to do with the attitude of the participants as it does with the practices followed.  The result of a requirements review should be a set of requirements that clearly articulates (at some level) the common understanding of those requesting the system and those building it. 

So, what are some good practices to follow?  Consider not only the good practices below, but also the characteristics of a requirement that communicate what is to be built: 

'        Review requirements formally and informally, early and often.

'        Use checklists to find typical defects.

'        Ensure that all requirements are in scope.

'        Check for characteristics of excellent requirements.

'        Check for error handling.

'        Make all requirements views consistent.

'        Ensure freedom from design and implementation details.

'        Ensure that requirements can serve as basis for design and testing.

Even though it is a good practice to review requirements early and often, it is the characteristics of excellent requirements that give evidence to why a set of requirements should be looked at more than once.  As indicated by the first question below, it is important to make sure that a requirement is understandable and unambiguous before we try to assess whether the requirement meets the other characteristics of a quality requirement:

Question

Requirement Characteristic

1.    Do you understand exactly what the requirement means?

unambiguous

complete

verifiable

This type of review is often called an ambiguity review.  Once a formal or informal ambiguity review is conducted, it should be followed by quality review(s) addressing the questions below:

Question

Requirement Characteristic

2.    Does the set of requirements make sense?                

consistent

traceable

modifiable

3.    Is the requirement valid and worth pursuing?                     

necessary

prioritized

feasible

 

Managing Requirements

Being prepared with not only requirements strategies (requirement types, requirement traces, requirement baselines) and a requirements process, but also with trained staff and appropriate tools sets the stage for the effective and efficient management of requirements.  Having a prioritization method will help the project manager set customer expectations appropriately and help the team members know what to work on first.  Prioritization and periodic baselines (snapshots of agreements) can effectively work hand in hand to manage scope.  Implementing the requirement trace strategy will help determine impact of change, completeness and justification.  Since requirements should be the basis for the project plan, tests and design/code, tracking identified requirements information (status, priority, source...) can help the project manager monitor the projects progress.

To manage requirements for a system involves:

'        Prioritization

'        Agreement

'        Change Control

Each of the above activities will be explored further, but the following are good practices to follow:

Preparation

4   Send managers and users to requirements training

4   Train requirements analysts

4   Train developers in application domain

4   Create a glossary

4   Evaluate prototypes

 

Requirements Management

4   Prioritize requirements

4   Analyze project feasibility

4   Baseline and control versions of requirements

4   Define a requirements change control process

4   Establish and charter a change control board

4   Perform requirements change impact analysis

4   Maintain history of requirements changes

4   Track requirements status

4   Measure requirements stability

4   Maintain a requirements traceability matrix

 

Project Management

4   Select appropriate software development life cycle

4   Base project plans on requirements

4   Renegotiate project commitments when requirements change

4   Manage requirements-related project risks

4   Track effort spent on requirements engineering

 

Prioritizing Requirements

Prioritization is making choices based on a set of criteria.  Whether we are working on requirements, design or code, the burning question is What do I work on first?  There are many things that should be considered before answering that question, namely:

'        What is the benefit?

'        What is the penalty?

'        What is the risk?

'        What is the cost?

Looking at any one of these aspects to the exclusion of another will lead to a skewed answer that promotes a continuously shifting target.  A prioritization model3 should be used to factually determine priority based on benefit, penalty, risk and cost.  Choosing a prioritization scale that is informative facilitates the making of smart decisions. 

Prioritization is not a one time activity.  There is usually a relative sense of importance for different facets of a project even at the beginning.  What is not well understood is that there needs to be a periodic sanity check to make sure the team is working on the most important things based on the additional information available since the last time we checked.  The failure to check and adjust only widens the expectation gap between what the customer needs and what the developer delivers.

 

Agreeing To Requirements

True agreement is based first on a common understanding and then on the content.  Historically, sign-off on a projects requirements is often followed by a myriad of changes.  The agreement we are seeking here is far more than a signatureit is the sign-on to requirements that are clearly understood, correct, complete and seen as feasible.  To promote a lasting sign-on, agreements should be built as requirements are uncovered, explored and reviewed.

 

Managing Change

Even a well-defined set of requirements tasks with effective elicitation/analysis techniques will not produce satisfactory results (or any result at all) if changes are not managed.  To understand change management, one must first look at the:

  • Types of requests for change 

  • Need to handle demands for change (which will  often step outside the defined procedures)

  • Need to find root cause of a defect so that requirements/design/can be living-breathing'

  • Fact that a Request For Change does not equal a Requirement!

 Change procedures need to reflect:

  • States for request for change such as:

o       Received

o       Reviewed for understanding

o       Assessed

o       (Decided)

'        Approved for development now

'        Approved for development later

'        Rejected

'        Information about the request such as:

o       Request identifier

o       Request name

o       Request description

o       Request type

o       Request create date

o       Request modify date

o       Request status

o       Request author

o       Request rationale

o       Request planned release

o       ...

'        Tasks which are to be followed such as:

o       Receive request for change

o       Review request for understanding

o       Assess value/impact of honoring the request

o       Determine disposition of the request

'        Approved for development now

'        Approved for development later

'        Rejected

o       Adjust schedule/budget/resources based on decision

o       Elicit/analyze/specify/validate requirements if needed

o       Create/modify/validate design based on agreed to requirements

o       Develop/modify system based on agreed to design

o       Verify implementation of the request

Often customers are confused by a perceived inconsistency in development teams willingness to incorporate new/modified requirement.  Actually, this is very predictable.  For instance, a new requirement introduced in ANALYSIS is no big deal, but a new requirement introduced during the late in CONSTRUCTION is a huge deal!  There should be a different Decision Matrix for each Phase because the risk of addressing a change varies as the development team moves from PLANNING to ANALYSIS (Inception to Elaboration) to CONSTRUCTION.

 

The 'Detail'

In the 'essence' there are a number of references to Karl Wiegers' work and website (www.processimpact.com).  Before deciding what appendices to include be sure to explore the 'goodies' available as you consider the suggested appendices below.

 

Requirement Type Definitions

The Requirements Management Process is based on recognizing that there are different types of requirements.  The primary requirement types are defined below:

 

REQUIREMENT TYPE DEFINITIONS

Requirement Type

Definition

Business Requirement

A business requirement is a goal of the organization requesting the system.

Constraint

A constraint is a limitation or restriction placed on the choices available to the project team for design and development of the system.

User Requirement

A user requirement is a task which the user must be able to accomplish using the system.

Functional Requirement

A functional requirement is one of the following:

'     Conversation between the system and user or another system requesting/providing information, such as:

o        The user must provide information to the system.

o        The system requests from the user.

o        The system requests from another system.

o        The system must provide information to another system.

o        The system must provide information to the user.

'     System feature that must be built into the system to satisfy the user requirements, such as:

o        Computation

o        Validation

Business Rule

A business rule is a law, policy, standard or procedure by which an organization functions.  It is a statement that defines or constrains some aspect of the business.   A business rule can be a:

'     Fact                           true statement

'     Constraint                   action restriction

'     Action enabler             trigger activity

'     Inference                     new fact

'     Computation                algorithm

Data Requirement

A data requirement is information the system or user requests/provides to satisfy a functional requirement.

Non-Functional Requirement

A non-functional requirement is a quality attribute that the system must have.  These attributes are not system features (functional requirements), but they do influence how the functionality of the system is implemented.  Non-functional requirements usually deal with some aspect of usability, performance, security, or are operational in nature.  The questions below will help uncover these quality attributes.

Usability

7      Ease of use/learning

WHAT qualities will make the system easy for people to learn or to use?

WHAT end-user skill levels/training needs must be accommodated?

7      Accessibility/   Section 508

WHAT are the accessibility guidelines with which the system must comply?

7      User satisfaction

WHAT qualities will the system need to have to meet user expectations?

HOW will the users satisfaction with the system be measured?

7      Documentation

WHAT types of user guides, operation manuals and online help are needed?

7      Training

WHAT type of training is expected to accept the system?

WHAT type of training is need to operate the system?

Performance

7      Availability

WHEN does the system need to be available for use?

7      Responsiveness

HOW fast does the system need to respond?

WHAT specific amount of time is necessary to complete a transaction(s)?

7      Reliability

WHAT is the expected length of time between system failures?

HOW well must the system respond to unexpected conditions?

WHAT is the impact when the system is not available?

WHAT are the factors required to establish the required system reliability?

7      Efficiency

HOW many system resources is it acceptable for the system to consume?

WHAT are the specific timeframes within which the system must complete an action?

7      Flexibility

HOW responsive must the system be to changing business process/business rules,?

HOW easy must it be to add new capabilities?

WHAT timeframes are prescribed for responding to a request for change?

7      Interoperability

WHAT other systems will interconnect with the system?

WHAT specific conditions apply to the system working with other systems/processes?

7      Capacity

WHAT volume of transactions is the system is expected to handle in a specified time period?

7      Scalability

HOW will transaction frequency increase over time?

WHAT are the system growth aspects which need to be considered?

7      Disaster recovery

WHAT is needed to be able to recover from a failure?

Security

7      User security

WHO has access to the system?

WHAT type of access does each user group need?

WHEN can the system be accessed?

7      Data security

WHO can see WHAT data? 

7      Integrity

HOW should the system react to invalid data?

WHAT preventive measures are necessary to protect against unauthorized access, prevent data loss, preserve valid data and ensure accurate processing?

WHAT integrity checks are needed to ensure proper data transmission?

WHAT audits are needed? .

Operational

7      Hardware

WHAT hardware is needed?

WHAT special environmental conditions are necessary for identified hardware?

7      Software

WHAT other software is needed?

WHAT special environmental conditions are necessary for identified software?

7      Network

WHAT are the network considerations?

7      Architectural

WHAT are the architectural considerations?

7      Data management

HOW will data be administered or controlled?

7      Production support

WHAT type of assistance is needed once the system is in production?

WHAT hours will this assistance be available?

7      Software licensing

WHAT software licenses are necessary?

WHAT is the maintenance agreement required?

7      Maintainability

WHAT is an acceptable level of complexity?

WHAT practices need to be followed to facilitate maintaining the system?

7      Testability

WHAT aspects of the system will be validated?

HOW will it be validated that the system was implemented correctly?

7      Deployment

HOW will the system be distributed for use?

WHAT users will be trained?

WHEN will the users be trained?

7      Data retention

HOW much historical information must be kept?  For how long?

7      Portability

WHAT other platforms must be supported by the system?

7      Reusability

WHAT functions of the system are intended to be shared with other systems?

 HOW easily should another system be able to  reuse the components of the system?

 

Requirement Trace Strategy

A trace defines an association between requirement types. As the Requirements Roadmap indicates many relationships exist between requirements and between requirements and other system development artifacts.  Traces are established between requirements during PLANNINGANALYSIS.  These relationships are critical to:

'   Managing the impact of change

'   Ensuring completeness

'   Ensuring there is justification for the development

The table below defines the trace to/trace from associations.  The tag may be used as an abbreviation for the requirement type in documenting traces.  Terms used to define the traces are as follows:

'   Should     a trace relationship is supposed to exist, but may not. (suspect)

'   Must        a trace relationship has to exist for the requirement to be valid.

'   May         a trace relationship can exist but, if one doesnt, the requirement is still valid.

To minimized risk a minimal set of traces is indicated on the Requirements Roadmap

and in the table below bolded traces indicate the minimum needed.

 

Requirement Type

Tag

Trace from/Trace to Association

Business Requirement

BR

Each business requirement should be traced to one or more user requirements.

Each business requirement may be traced to one or more constraints.

Each business requirement may be traced to one or more non-functional requirements.

Each business requirement may be traced to one or more business rules.

User Requirement

UR

Each user requirement must be traced from at least one business requirement.

Each user requirement should be traced to one or more functional requirements.

Functional Requirement

FR

Each functional requirement must trace from at least one user requirement.

Each functional requirement may trace from one or more data requirements.

Each functional requirement must be traced from one or more test cases.

Non-functional Requirement

NFR

Each non-functional requirement must be traced to at least one requirement.

 

(The actual content of the non-functional requirement determines to which requirement /requirement type the trace will be created.)

Each non-functional requirement must be traced from one or more test cases.

Business Rule

RULE

Each business rule may be traced from a Business Requirement.

Each business rule should be traced to one or more requirements (usually functional requirements). 

 

(The actual content of the business rule determines to which requirement/requirement type the trace will be created.)

Data Requirement

DATA

Each data requirement should be traced from one or more requirements (usually functional  requirements). 

 

(The actual content of the data requirement determines to which requirement/requirement type the trace will be created.)

Constraints

CON

Each constraint may be traced to one or more requirements. 

 

(The actual content of the constraint determines to which requirement/requirement type the trace will be created. Constraints may not impact any requirements, but instead impact design and development choices.)

 

Requirement Baseline Strategy

A requirements baseline consists of taking a 'snapshot' of the requirements (all the requirements or just a sub-set) as they exist at a particular moment in time. To be included in a snapshot, a requirement should have the minimum information identified in the Requirement Information Structure.  This snapshot can establish an informal or formal baseline.  An informal baseline is an agreement by the project team that the requirements in the snapshot are correct as of that point in time.  This does not require an official sign-off but from this point on any changes to a requirement in the informal baseline need to be documented in the change history log.  It is recommended that informal baselines be created at several points in the requirements process as suggested by the camera icon in the Requirements Management Task Diagram.

A snapshot to create a formal baseline should occur at three points in the requirements process.  The first point is prior to development of the software to implement the requirements, the second point prior to the requirements and software going to validation and the third point when validation is complete. These points are shown in the Requirements Management Task Diagram by a picture of a gate.  Once a formal baseline is created any changes to a requirement must be handled according to the formal projects procedure for managing change.

Any requirements document containing baselined requirements should be under version control.

A possible baseline naming convention follows: 

'        Project Name + Release + Business Requirement Baseline

'        Project Name + Release + Business/User/Functional/Non-functional Requirement Baseline

'        Project Name + Release + Requirement Baseline

 

Requirement Versioning

Requirements versioning is the process of documenting and maintaining a history of all changes to a specific requirement. The primary purpose of versioning an individual requirement is to ensure that the project team is working from the exact same set of requirements. An additional and equally important purpose of versioning is to enable the team to determine how and why an individual requirement has changed over time. Finally, versioning facilitates the auditing of the requirements by internal and external groups to ensure that the delivered software accurately reflects the requirements.

At a minimum, the following information (or attributes) should be associated with each requirement:

'        Requirement Identifier

'        Requirement Version

'        Requirement Type

'        Requirement Name

'        Requirement Description

'        Requirement Change History

'        Requirement Status

'        Requirement Priority

'        Requirement Owner

'        Requirement Trace Information

 

It is the first two attributes that will facilitate requirements versioning:

'   Requirement Identifier         This identifier uniquely names a requirement. 

The format of the requirement identifier can be determined by the project but it can be as simple as 1, 2, 3, etc.  The requirements should be identified in order of discovery, so a business requirement could be #1, a user requirement #2, another business requirement #3, a functional requirement #4 and so forth.  When the requirement identifier includes the requirement type, then requirements can be sorted into the appropriate group such as business, user, functional, etc.

'   Requirement Version           This number uniquely identifies a specific depiction of  a requirement.

Number 

Each requirement begins as version 1.0.  As changes are made to the requirement its version number will change by whole number increments, e.g.; 1.0 to 2.0. In addition to incrementing the version number when a change occurs, the actual change made must be documented in a change history log.  A reason for the change must also be recorded after there has been an agreement (baseline) on a set of requirements.

 

RM Task Descriptions

The guideline for each RDM Task consists of the following information:

'        Inputs/Outputs

'        Task Summary

o       Overview

o       Specific Guidance

'        Steps

o       Step Descriptions

o       Technique

o       Template

o       Tool

o       Tool Procedures

o       Key Driver

 

The legend for the Tool Procedures is:

INSTRUCTION

REQUIREMENT TYPE

'        Attribute

'        Tab or Category

o       User-defined Attribute

o       Referenced artifact

SAMPLE RM Task Description

 

Input

 

Output

7      Project Charter (.reviewed)

7        Project Measures Of Success (reviewed)

PM

 

 

7       

 

7      Assumptions (reviewed)

RDM

 

 

7       

 

7      Constraints (reviewed)

RDM

 

 

7       

 

7      Business Requirements (reviewed)

RDM

 

 

7       

 

7      ToBe Business Process (reviewed)

RDM

 

 

7       

 

7      Possible Roles (identified)

RDM

 

 

7      Roles (analyzed)

RDM

7      Possible Tasks (identified)

RDM

 

 

7      User Requirements (analyzed)

RDM

7       

 

 

 

7      Functional Requirement  (analyzed)

RDM

7      Initial Context Diagram (developed)

RDM

 

 

7      Context Diagram (developed)

RDM

7      Initial User Class Description (developed)

RDM

 

 

7      User Class Description (developed)

RDM

7      Initial End-user/Role Matrix (developed)

RDM

 

 

7      End-user/Role Matrix (developed)

RDM

7      Project Glossary (developed)

RDM

 

 

7       

 

 

7      Functional/Organization Resource Matrix (developed)

RDM

 

 

7       

 

 

7      Requirement Development Techniques (selected)

RDM

 

7       

 

 

RDM     Requirement Development and Management

PM    Project Management

TM      Test Management

EA        Enterprise Architecture

 

 

Task Summary

 

Overview

 

Explore user requirements to discover functional requirements is:

'        Ensuring that all roles and associated tasks have been identified as candidate user requirements

'        Determining user requirements

'        Analyzing each user requirement to uncover functional requirements

 

The purpose of this task is to ensure that user requirements and functional requirements are elicited, analyzed, categorized, specified and associated with the appropriate business requirements.

 

 

 

User requirements and functional requirements are explored together because functional requirements are a natural extension of user requirements and will be discovered during use case analysis.

 

 

The roles and associated tasks identified in conjunction with the business requirement activities provide candidate user requirements.  Since much of the requirement discovery process depends on understanding the user and the users needs, it is important to ensure that all roles and associated tasks have been captured.

 

As each task (user/external system task) is explored, functional requirements (conversation and system features) begin to emerge.  Typically, you will find that some of the candidate user requirements identified earlier may end up being just a step within a task while others will be confirmed as user requirements. 

 

Select a candidate user requirement and ask the questions below to uncover associated functional requirements:

 

Question

Identifies

'   What task must the user/external system be able to do to accomplish the business goal?

user requirement

'   What steps make up this task

functional requirement

'   Do any of the steps need to be decomposed?  If so, what are the sub-steps?

functional requirement

 

So, if we ask the right questions when we are exploring user requirements, the functional requirements will 'fall out' naturally.  Keep in mind that some of these steps (functional requirements) will be conversation between user/external system and the system being built and others will be system features which are not visible to the outside world.  Typically, the system being built must support all of the steps in a task.  For instance, if a user/external system must supply the system with information, the system will bundle together related functional requirements (conversation) and provide a mechanism for the user/external system to supply that information.  Additionally, if features such as validations and calculations are needed the system will perform these functions.

 

As you might guess, discovering user requirements and the associated functional requirements is not a one-way street or a one time activity. 

 

As you engage in activities to explore

you will likely discover

'     User requirements

'     Functional requirements

'     Non-functional requirements

'     Data required

'     Business rules

'     Constraints

'     

Likewise, as you engage in activities to explore

you will likely refine/add to

'     Non-functional requirements

'     Data required

'     Business rules

'     User requirements

'     Functional requirements

 

 

Specific Guidance

 

As the steps (functional requirements) are explored, the data required will emerge.  It is a good practice to capture:

'        What you know about the data required even if it is just the type of data that is needed

'        Only business/logical data and save any references to physical data (even if it exists) until design activities commence

 

 

 

Steps

Technique

Template

Tool

Tool Procedure

Key Driver

1.      Group possible user requirements by role recognizing that some candidate user requirements may be:

'        Tasks performed by more than one role

'        End up being just a step within a task (user requirement)

Use Case Diagram

 

CaliberRM

REFERENCE use case diagram

USER REQUIREMENT

'    Reference  ( at user requirement category)

o       Use Case Diagram

Requirements Analyst

2.      For each user requirement (starting with the most prominent, important user tasks), identify the following:

'        Actor(s)

'        Pre-conditions

'        Post-conditions

'        Flow Of Events (steps)

'        Alternate paths (alternate set of steps)

'        Exceptions

Use Case Analysis

Use Case

CaliberRM

CAPTURE user requirements

USER REQUIREMENT

'    Name

'    Description

'    Status (Proposed)

'    Use Case Analysis

o      Actor(s)

o      Pre-conditions

o      Post-conditions

o      Flow Of Events

o      Alternate Paths

o      Exceptions

 

Requirements Analyst

3.      Identify functional requirements (steps) and document any data required by a functional requirement in the requirements description.

 

 

CaliberRM

COPY Flow of Events to  MSWord (temporary) and make Heading 1

 

IMPORT Flow of Events as functional requirements

FUNCTIONAL REQUIREMENT

User Requirement Name A

FR1

FR2

...

User Requirement Name B

FR11

FR12

...

CAPTURE functional requirements

FUNCTIONAL REQUIREMENT

'    Name

'    Description

'    Status (Proposed)

Requirements Analyst

4.      Refine initial versions of:

'        A context diagram that illustrates what is to be built and what interacts with it. 

 

 

'        A brief description of each role including the characteristics of each user class

 

 

 

'        A matrix associating specific end-user groups with roles

 

 

CaliberRM

REFERENCE context diagram

     REQTS DOC ADMIN

'        Project Name

o       REFERENCE context diagram

Requirements Analyst

 

 

CaliberRM

CAPTURE user class information

     REQTS DOC ADMIN

'        Project Name

o       REFERENCE user class information

 

 

CaliberRM

REFERENCE matrix

REQTS DOC ADMIN

'        Project Name

o       REFERENCE End-user/Role Matrix

5.      Determine <company> requirement details.

 

 

CaliberRM

CAPTURE <company>requirement details

USER REQUIREMENT/

FUNCTIONAL REQUIREMENT

'        <Company> Detail

o       Source

o       Targeted Release

o       Effort Level

o       Complexity Level

o       Technical Owner

o       Business Owner

o       Short Description

Requirements Analyst

6.      If necessary, provide vendor product information.

 

 

CaliberRM

CAPTURE vendor/vendor product information

USER REQUIREMENT/

FUNCTIONAL REQUIREMENT

'        Vendor Product

o       Vendor Name

o       Resolution Approach

o       Resolution Description

o       Enhancement/ New

o       Vendor/ <Company> Responsibility

o       Vendor Requirement Identifier

Requirements Analyst

7.      Using the established requirements trace strategy, ensure that relationships between the following types of requirements are established:

'        Business requirement

'        User requirement

'        Functional requirement

 

 

CaliberRM

TRACE user requirements to related functional requirements

Requirements Analyst

8.      Determine the relative importance of each of the following to projects success:

'        User requirement

'        Functional requirement

Prioritization Model

 

CaliberRM

CAPTURE priority

USER REQUIREMENT

'        Priority

'        <Company> Detail

o       Priority Number

CAPTURE priority

FUNCTIONAL REQUIREMENT

'        Priority

'        <Company> Detail

o       Priority Number

Requirements Analyst

9.      Obtain general consensus on which of the following are significant architecturally, important to the user or considered high risk:

'        User requirements

'        Roles

 

 

 

 

 

10.    Obtain general consensus on the following for identified user requirements:

'        Functional requirements (basic flow of events)

 

 

 

 

 

 

Role Definitions

The roles described below encompass the responsibilities of the system development process.  It is important to realize that:

'        Each role is a collection of responsibilities and does not equate to an organizational title. 

'        One or more people may be assigned to a role, and one person can be assigned one or more roles.

'        The person filling the role may indeed be a surrogate, such as a person standing in for a real End User.  The use of surrogates for any role, particularly the End User role, introduces risks which must be documented and mitigated.

'        A particular role may not be needed on a project if the scope of the project does not require the responsibilities involved.

'        Some roles will bring the perspective of the business/end users while others will provide a project or enterprise viewpoint.

'        Each role has at least one of the following as a primary focus:

1.      Manage project effort

2.      Provide requirements

3.      Analyze requirements

4.      Design system/tests to address requirements

5.      Develop system/tests based on approved design

6.      Prove system meets requirements

7.      Guide development for the enterprise

'        There are a number of topics where experts are needed.  A person filling a Subject Matter Expert role specializes in one of a wide variety of topics, such as a policy, a law, an existing system, a methodology or tool.  A Subject Matter Expert typically provides information about a specific topic and may participate in the verification that related requirements have been fulfilled.  Recognizing those areas where specialized knowledge is needed is the first step in identifying the appropriate resource to provide the required input and verification.

'        Each person filling a role is expected to participate appropriately in each system development task and be accountable for the responsibilities associated with that role. 

'        Over and above these responsibilities is the essential awareness of other roleswhat they are doing and what they need to do their jobs effectively.   So, to say be a good communicator is just not enough.  To truly and effectively communicate and collaborate means you not only recognize what information another role needs from you, but also that you define success from the perspective of the entire effort, not just your part.

Primary Focus

Role

Definition

1

2

Business Sponsor

'     Finance project

'     Provide strategic direction

'     Assign knowledgeable business resources to the project who are empowered to make binding decisions which are respected by their peers

'     Approve requirements for analysis/implementation

'     Approve milestone dates and level of effort expect of business resources

2

3

6

 

Business Representative

'     Identify user classes and the tasks each user class must be able to do

'     Verify requirements

'     Be accountable for a unified set of requirements that are complete and accuracy representation of business and user needs

'     Make binding decisions

'     Develop conceptual test cases

'     Ensure developed system meets user needs

2

3

6

Business Subject Matter Expert

'     Be accountable for the completeness and accuracy of information provided in area of expertise

'     Verify requirements in area of expertise

2

6

End User

'     May provide information on a specific user task(s)

'     May test a specific user task(s)  

1

Project Manager

'     Manage resources, budget and schedule for the project 

'     Coordinate with other projects

'     Accountable for the quality of the system and the execution of the process

3

Requirements Analyst

'     Facilitate the elicitation, analysis, specification and validation of requirements

'     Encourage the participation of appropriate business/system resources in requirements definition, review and testing

'     Be accountable for testable requirements that reflect stated business and user needs

'     Determine appropriate requirement elicitation techniques

2

3

6

Current System Subject Matter Expert

'     Be accountable for the completeness and accuracy of information provided in area of expertise

'     Verify requirements in area of expertise

7

Enterprise Architect

'     Develop and communicate technology vision

'     Identify enterprise architectural solutions to business objectives and their associated value/ramifications

'     Guide product technology roadmaps for cross application development

'     Develop enterprise system architecture standards to which all systems must adhere

'     Validate key technology selection and product design options across the enterprise

4

System Architect

'     Develop a system architecture adhering to enterprise architecture standards

'     Oversee integration of systems

'     Identify system architectural solutions to business objectives and their associated value/ramifications

4

System Analyst

'     Review requirements for understanding and requesting clarification of requirements if necessary

'     Develop appropriate analysis models (data, process,) to determine a preliminary system design

'     Develop a detail system design allocating requirements to system components

7

Data Architect

'     Develop an enterprise data architecture

'     Develop enterprise data architecture standards to which all systems must adhere

'     Oversee data implementations

4

Data Analyst

'     Develop logical and physical data models

'     Design data structures consistent with the defined data architecture standards

'     Develop a data migration strategy for moving data from existing structure(s) to new structure(s)

5

Database Administrator

'     Develop and maintain data structures

'     Migrate data from existing structure(s) to new structure(s)

'     Monitor database performance

'     Perform database tuning

'     Perform database backup/recovery

5

System Developer

'     Review requirements for understanding and requesting clarification if necessary

'     Identify additional non-functional requirements to include constrains, reusability, interoperability, performance, maintainability,...

'     Request clarification of requirements if necessary

'     Develop prototype(s) for unclear portions of the system

'     Implement detail system design developing prototypes as needed

'     Test develop component

4

5

System Test Designer

'     Review requirements for understanding requesting clarification if necessary

'     Develop test strategy and test plans to validate requirements

'     Develop/refine test cases and test scenarios

'     Define test environment

'     Evaluate test coverage, test results and test effectiveness

6

System Tester

'     Build test environment

'     Test developed system using established test procedures

'     Perform regression testing

'     Ensure appropriate disposition of all defects

 

Artifact Overview

SAMPLE Artifact Overview

 

Decision Matrices

 

The SAMPLE Decision Matrix provided below is for replacing an existing system during CONSTRUCTION and illustrates one way of knowing what type of requests will be addressed or even investigated. 

SAMPLE Decision Matrix

Requirement Information Structure

 

Requirement Type

Attribute

Attribute Definition

BUSINESS

REQUIREMENT

Standard (minimum)

Requirement Identifier

This identifier uniquely names a requirement.

 

Requirement Version Number

This number uniquely identifies a specific depiction of a requirement.

 

Requirement Type

This type identifies the category to which a requirement belongs as one of the following:

'   Business requirement                      BR

'   User requirement                              UR

'   Functional requirement                   FR

'   Non-functional requirement           NFR

'   Business rule                                    RULE

'   Data requirement                             DATA

'   Constraint                                         CON

Requirement Name

This name is a simple summary of the requirement providing a way to refer to a requirement so that its meaning is evident.

Requirement Description

This description indicates the meaning of a requirement.

Requirement Change History

This text identifies any changes made to the requirement and should include what changed, who changed it, why it was changed and when it was changed.

Requirement Status

This code identifies the status of a requirement as one of the following:

'        Proposed

'        Analyzed

'        Reviewed

'        Approved for development now

'        Approved for development later

'        Rejected

Requirement Priority

This code identifies the importance of the requirement as one of the following:

'        Must have

'        Should have

'        Nice to have

Requirement Owner

This name identifies the person who can make decisions about the requirement.

Requirement Trace Information

This text identifies associations that a requirement has with other requirements or with system develop

Project Specific

Targeted Release

This identifier indicates the release targeted to include the requirement.

Actual Release

This identifier indicates the actual release that includes the requirement.

Risk

This text identifies the risks related to a requirement that could endanger the success of the project.

Complexity

This text indicates how difficult the requirement is to implement. 



 

USER

REQUIREMENT

Standard



 

User Task Analysis

Actors

This name identifies a role that interacts with the system.

Pre-conditions

This list states what conditions must be true before the user task can begin.

Post-conditions

This list states what conditions must be true after the user task ends.

Flow of Events

This list identifies a basic set of steps for a user task.

Alternative Courses

This list identifies an alternate set(s) of steps for a user task.

Exceptions

This list identifies situations in which the user task can not be successfully completed.

FUNCTIONAL

REQUIREMENT

Standard



 

 

 

NON-FUNCTIONAL REQUIREMENT

Standard



 

Non-functional Category

This name identifies one of the following  non-functional categories for each non-functional requirement:

'    Usability

o        Ease of use/learning

o        Accessibility/Section 508

o        User satisfaction

o        Documentation

o        Training

'    Performance

o        Availability

o        Responsiveness

o        Reliability

o        Efficiency

o        Flexibility

o        Interoperability

o        Capacity

o        Scalability

o        Disaster recovery

'    Security

o        User security

o        Data security

o        Integrity

'    Operational

o        Hardware

o        Software

o        Network

o        Architectural

o        Data management

o        Production support

o        Software licensing

o        Maintainability

o        Testability

o        Deployment

o        Data retention

o        Portability

o        Reusability

NON-FUNCTIONAL REQUIREMENT

Standard



 

 

 

BUSINESS

RULE

Standard



 

 

 

DATA

REQUIREMENT

Standard



 

 

 

CONSTRAINT

Standard



 

 

 

 

Change Control Process

<The SAMPLE Change Control Process below not only shows the steps required to make a decision on and implement a request for change, but also indicates what Borland tools can support this process.  The red box indicates that a decision making process is needed to "assess value/impact/feasibility".  Karl Wiegers' www.processimpact.com will provide you with a number of "goodies" to help with prioritization and impact analysis.>

 

Request For Change States

SAMPLE Request For Change States

Summary

When designing and developing a RM Practice for your company is it is important to provide guidance that is embraceable and aligned with RM best practices.  A few key things to keep in mind are:

  • Make sure the basic components are stable (RM strategies, RM tasks, system development roles, RM task/role participation,...).
  • Know your audience because the tolerance for prescriptive guidance varies. 
  • Decide on a set of techniques, but keep it simple!
  • Determine what tool support will be available and try it out.
  • Pilot your RM process with a small group before deploying the RM Practices...The 'Essence' to the organization.
  • Identify the evangelists who will sell their peers on effective and efficient requirements development and management activities.

The Capability Maturity Model (CMM) clearly places the development and management of requirements as key processes for attaining Level 2 and Level 3.  What this really means is that by effectively and efficiently managing requirements your organization will be better equipped (more mature) to produce quality products.  Creating a sound, embraceable RM Practices...The 'Essence'  is an vital step toward doing just that!

 

References

  1. Adapted from Wiegers, Karl. 2003. Software Requirements. Redman, Washington: Microsoft Press.
  2. Adapted from Wiegers, Karl. 2003. In Search Of Excellent Requirements
  3. Adapted from Wiegers, Karl. www.processimpact.com

  Latest Comments  View All Add New RSS ATOM

Move mouse over comment to see the full text

Server Response from: ETNASC03