Requirements Definition



> The development and approval of project requirements definition is an essential practice for our projects. The purpose of requirements definition is to determine and clearly document the details of the customer's requirements and to evaluate and recommend the appropriate solution prior to the development of the project plan.

Objective

bm70115.gif
     Define the user's functional and operational requirements

bm70115.gif
     Identify the key business and technical constraints

bm70115.gif
     Explore alternative system solutions that satisfy the user functional requirements and constraints

bm70115.gif
     Provide an evaluation and selection of a preferred systems solution and an evaluation of the impact the new system will have on the business

bm70115.gif
     Specify a testing strategy which will validate that requirements have been met

bm70115.gif
     Assure that all of these elements are agreed upon and understood in a common way by customer, users, project management, solution providers, and quality assurance

Benefits

bm70115.gif
     Provides a clear Checkpoint for management approval of the project direction and deliverables

bm70115.gif
     Increases the probability of success on the project through preparing, as completely as reasonably possible, the project requirements definition

bm70115.gif
     Improves the customer's ability to document and approve the attributes of the solution

bm70115.gif
     Improves the quality of information used by the project team to accurately estimate the project's cost and schedule

bm70115.gif
     Improves the customer's and project team's shared understanding of the baseline scope of project deliverables, so any subsequently agreed-upon changes can be documented and their impacts on project schedule or resources can be understood

Documentation

bm70115.gif
     The requirements are recorded in the Requirements Definition Document (RDD). This document is reviewed (either separately or concurrently with the Project Plan) through a Peer review and approved through a Management review with the sponsor and appropriate management. The approved version is retained in the project notebook.

bm70115.gif
     Copies of the RDD should be distributed to those identified in the communications matix, including a copy to the IT JB Danforth Project Office

Requirements Definition Process

Introduction

Requirements definition includes all of the activities associated with the analysis phase of the Project Road Map. The RDD is the prime deliverable from this phase of the project. The document represents the "blueprint" for the new system and will be used to determine tasking and to control scope. The requirements are owned by the customer and recorded as part of the RDD for the mutual understanding and agreement between the customer and the project team. The RDD does not contain, but must reference, each technical analysis tool or model results and the evaluation of alternative software and/or suppliers.

The analysis work for a typical project consists of the following steps:

bm70115.gif
     Develop the user functional requirements--i.e., what is to be built or delivered to the customer

bm70115.gif
     Define the business and technical constraints that need to be incorporated into the project

bm70115.gif
     Develop alternative system solutions that satisfy the user functional requirements and fit within the business and technical constraints

bm70115.gif
     Evaluate and select a preferred systems solution

bm70115.gif
     Determine the impact of the new system on the business

bm70115.gif
     Specify a high-level testing strategy

bm70115.gif
     Prepare the requirements definition document

As can be seen from the above outline, requirements definition is a significant amount of work that requires a potentially large amount of time and resources for most projects. Also, the quality of the work accomplished at this stage is critical to the downstream quality and success of the overall project. If user requirements or business constraints are left out or are incorrectly stated at this phase, it is very likely that the project will miss its objective or incur expensive rework and project delays when the errors are discovered.

Experience shows that there is a greater likelihood of success for the project if the requirements-related work is done rigorously and completely with full involvement by the customer. It is important to develop an approach that will investigate the identified needs of the business and consider all reasonable solutions and impacts. Ideally, the customer should direct this effort and supply the majority of resources and access to the people that can provide the essential business information. The project team is a major participant and ensures the completeness and accuracy of the development.

Approval of the RDD is an essential Checkpoint at the end of the analysis phase to define the baseline scope of project deliverables.

The valid variation in analysis phase activities from project to project is second only to the wide variety of successful implementation phase plans. If a given project will do software evaluation and selection, or object-oriented software development, or infrastructure roll-out, or data modeling and strategic planning, then more specific, tailored processes are available to guide the Project Manager. See the IT Best Practices for a recently defined process for software acquisition, and contact the Software Engineering Methods Manager in the JB Danforth Project Office for information on the LBMS Process Library.

Develop the User Functional Requirements

The development of the user functional requirements is an opportunity to thoroughly study a business or a specific aspect of a business and to determine its needs. The primary piece of information that is sought during this investigation includes:

bm70115.gif
     What does the current system do?

bm70115.gif
     What does the new system need to do?

There are a variety of information sources and information gathering techniques that are useful in the collection of the functional requirements. The primary sources are:

bm70115.gif
     The Project Summary Statement that was prepared in the opportunity identification phase of the project

bm70115.gif
     Materials from the existing system, such as:

 

bm6053.gif
     Program Listings

bm6053.gif
     System Reports

bm6053.gif
     Application Screens

bm6053.gif
     User documentation

bm6053.gif
     System Change Requests

bm6053.gif
     Problem Logs

 

bm70115.gif
     Strategic business plans

bm70115.gif
     Business management

bm70115.gif
     System users

The emphasis for data gathering in this phase is on:

bm70115.gif
     Business events and how they should be handled

bm70115.gif
     Interfaces to other systems

bm70115.gif
     Inputs to the system

bm70115.gif
     Outputs from the system

bm70115.gif
     Data resources needed by the system

bm70115.gif
     Operational volumes

bm70115.gif
     System performance requirements

It is important that the customer perform a prominent role in the collection and analysis of the requirements data. The customer needs to verify (and provide the approval) that the requirements, as defined, truly represent what the customer wants in the final product.

There are a variety of approaches that can be used to gather information from customers. The approaches can include:

bm70115.gif
     Joint Analysis of Requirements (JAR) sessions, in which a broad representation of the eventual user community are empowered with a creative voice, so they can come to agreement on the real needs and how they should be prioritized

bm70115.gif
     Individual interviews based on a standard set of questions

bm70115.gif
     Surveys that target specific information from specific customers or user groups

bm70115.gif
     Focus groups that utilize current techniques for data gathering and analysis from diverse participants

bm70115.gif
     Prototyping for the purpose of understanding and demonstrating user needs

Translate the existing system documents and materials into useful and clear representations of what is being done currently. These should encompass:

bm70115.gif
     Business processes and procedures

bm70115.gif
     Interfaces to other systems

bm70115.gif
     System inputs and outputs

bm70115.gif
     Data resources

bm70115.gif
     How the current system works

bm70115.gif
     A description of current processing volumes and system performance

bm70115.gif
     A description of anticipated processing volumes and desired system performance criteria

bm70115.gif
     A data dictionary for the project

The information should be displayed in consistent graphical forms. All of the work necessary to capture and display this information can be done Guidely or with conventional PC tools (word processors and graphical programs). However, there are a wide variety of Computer Aided Software Engineering (CASE) tools available that could assist in the capture, maintenance and display of this most valuable material. It is best to learn how to use these tools in advance of the project activity, or to hire experts that can direct their usage, rather than encumber the project with the learning curve that will be required to effectively employ these tools.

Define the Business and Technical Constraints

In addition to the user functional requirements, there is a collection of business and technical factors that constrain or limit the choice of solutions. It is very important that the customer perform the prominent role in the definition of these criteria and fully understands the constraint's impact on the final solution.

Typical business constraints fall into the areas of:

bm70115.gif
     Capital dollars that may have been budgeted for this project in advance

bm70115.gif
     A startup schedule that has been defined or tied to another event

bm70115.gif
     Policies of the business unit

bm70115.gif
     Government regulations that need to be satisfied or adhered to

bm70115.gif
     Prescribed operational characteristics or performance levels

Technical constraints are generally in the areas of:

bm70115.gif
     IT standards

bm70115.gif
     Technical resource availability

bm70115.gif
     IT capability

bm70115.gif
     Reliability requirements

Develop Alternative System Approaches

Using the model developed to describe the business functions of the new system and the relevant system constraints, develop alternative views of the new system, including the null alternative where nothing changes. The challenge in this activity is to be creative and think beyond the boundaries of "this is the way it's always been done". The objective of the new system is not to merely automate the existing processes, but is to improve overall business processes and capabilities. It is important to challenge the status quo, and ask questions like:

bm70115.gif
     What business process might be eliminated?

bm70115.gif
     What business process can be streamlined?

bm70115.gif
     How can we improve the quality of the business's product?

bm70115.gif
     How can we improve the quality of the business's service?

bm70115.gif
     How can we reduce business costs?

For each view, develop alternative models of:

bm70115.gif
     The automated processes

bm70115.gif
     The Guide processes

bm70115.gif
     Interfaces between the Guide and automated systems, as well as interfaces to other systems

bm70115.gif
     The data

If a package purchase is a feasible approach to your project, develop a list of qualified suppliers that can provide knowledge, skill and specific hardware or software products that support an aspect of the solution alternatives. Also, identify other companies that have implemented similar systems with which you can compare the system and the supplier performance. During the next step of the requirements process, it will be important to contact both groups to gather additional information that will help in the selection of the best approach for the customer.

If an in-house development is being considered, review alternative development approaches with the appropriate IT organizations. System environments, development techniques and other considerations must be examined in the alternative identification.

Finally, review the alternative solutions with the customer. Validate that the solutions are consistent with their earlier expectations and that the identified approaches are acceptable.

Evaluate and Select a Preferred Systems Solution

In this step of the process, the goal is to narrow the list of alternative solutions to the "best fit" for the customer. To accomplish this, a large amount of information will be gathered from a wide variety of sources. In order to synthesize the material into useful information, it is important to define the data required from the internal and external suppliers, the information required about them, and the information required about their products.

Reference the IT best practice -- IT Methodology for Evaluation and Testing Projects. This process is owned by the Applied IT R&D group and contains a process and formats for the comparative evaluation of software products, both in the Manufacturing Information Technology Lab and in evaluation projects.

Prior to contacting external suppliers, it is best to work with the customer to define the evaluation criteria and their relative weightings, for both the suppliers and the products. These criteria should take into account areas, such as:

bm70115.gif
     Business stability

bm70115.gif
     Business application knowledge and expertise

bm70115.gif
     Technical capability

bm70115.gif
     Technical approach or sophistication

bm70115.gif
     Fit with business requirements

bm70115.gif
     Quality assurance processes

bm70115.gif
     Future product direction

bm70115.gif
     On-going support

At the same time, prepare a standard set of questions that will yield useful information from personal visits or phone interviews to other customers with similar systems. There are a variety of ways to solicit information from the suppliers. It is important to use whatever techniques work best for the specific project and situation. The more successful approaches are:

bm70115.gif
     Formal or informal request for information (RFI)

bm70115.gif
     Request for proposal (RFP)

bm70115.gif
     Visits to the suppliers for demonstrations

bm70115.gif
     On site demonstrations by the suppliers

bm70115.gif
     Trade shows or seminars where as large number of suppliers are present

bm70115.gif
     Visits to other companies that have recently implemented similar systems

In addition to the supplier information, it is important that the following material be developed for each of the alternative solutions:

bm70115.gif
     Development costs

bm70115.gif
     Operational costs

bm70115.gif
     Business risk

bm70115.gif
     Project risks

bm70115.gif
     Ongoing operating considerations

bm70115.gif
     Business benefits

The solution should be stated in terms of data, hardware, software, telecommunications and the procedures people will follow. To the appropriate level of detail, all inputs (screens, etc.), processes (mini specifications), and outputs (reports, inquiries, etc.) should be defined.

After all the information has been collected and put into a meaningful form, members of the project team and selected customers should evaluate the alternatives according to the previously determined criteria and select a preferred solution. This preferred solution and the associated rationale will be presented to the project sponsor and the appropriate business management for final approval. Estimates should be used to develop the budget for the Project Plan, and the capital allocation for the project where the system costs will be capitalized.

Determine the Impact of the New System on the Business

Having determined both the Guide and automated aspects of the new system solution, it is possible to evaluate the impact of the new system on the customer's operation and organization. A team of project members and customers should assess the impact of the new system in the following areas:

bm70115.gif
     Procedures and work flows

bm70115.gif
     Business organization

bm70115.gif
     Data management

bm70115.gif
     Employee skills

bm70115.gif
     Facilities

bm70115.gif
     Security

The project will need to address the impacts that are identified with this analysis during the implementation of the system. If not, the customer will need to take action separately to deal with the impacts.

Specify a High-Level Testing Strategy

The next step in the process is to determine the testing strategy. The System Testing Process best practice is available to help specify this strategy and to guide the corresponding work in later project phases: test planning, test design, and the various stages of testing itself. The testing strategy includes defining the steps to be taken to ensure that the customer will indeed receive the system that has been defined and that it will operate in a reliable manner. This activity draws from the prior work in the requirements definition process:

The first step in the development of the testing strategy is to determine the system acceptance criteria with the customer. The acceptance criteria should be defined in terms of:

bm70115.gif
     Measurable functional criteria - the functional capability that must be present in the system

bm70115.gif
     Measurable operational criteria - response time, volumes, usability, etc.

In addition, the test approach, environment, control process, and resource requirements should be specified. The objective of the testing should be to discover where requirements are not satisfied and where the system is not of high quality so the corresponding improvements can be made before the system is delivered.

As part of the test strategy, it is important to define the role of quality assurance throughout the implementation process and to emphasize wherever possible the importance and value of the technical peer review process as well as the planned test activities. Refer to the Quality Assurance (major section) of processes found in the ITPM for more detail.

Requirements Definition Document Checklist

Assemble the material from the process steps above into a document that can be reviewed and approved by the project sponsor and business management. In addition, the detailed technical support documents are referenced in the implementation planning phase to prepare the project plan information, and then again in the implementation phase to build the detailed design and subsequently to verify that the system as delivered meets the requirements. As a document format, refer to PM Guide in the analysis phase Form or Standard Document Template for a requirements definition document shell. Also available there is an actual sample RDD from a recent project.

The approved RDD package provides the required deliverable to proceed with the preparation of the project plan in the implementation planning phase of the project. To obtain the approval, the RDD is to be reviewed through the red and Management processes to ensure the accuracy and completeness of the document. After the acceptance of the requirements definition, the project's change control process should be employed to manage any changes to scope as defined by the RDD.

 

 

 

[Name of Business]

 

[Name of Project]

 

Requirements Definition Document

 

 

 

 

 

Use a graphic symbol for the project, where appropriate.

 

 

 

 

 

 

 

 

 

Prepared By:

 

Name     

[Project team names or Project Manager's name representing the team]

Title

 

Business Unit

 

Business

 

Date

[Report date]

bm2270.gif
 

     I.      Management Summary

bm2280.gif
 

     II.      RDD Objectives

bm2290.gif
 

     III.      System Requirements Overview

bm2300.gif
 

     IV.      Recommended System

bm2310.gif
 

     V.      Documentation

bm2320.gif
 

     VI.      System Displays

bm2330.gif
 

     VII.      System Constraints

bm2340.gif
 

     VIII.      Test Strategy

bm2350.gif
 

IX.      Risk Analysis

bm2360.gif
 

          Appendices

bm2370.gif
 

 

See also:

For providing as the primary deliverable in the analysis phase

Project Process

For maintaining the approved document as a file copy in the project notebook

Project Notebook

Request for Proposal

For assembling the project estimate based on vendor inputs according to system specifications

 

 

JB Danforth Company Proprietary