> 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.
Define the user's functional and operational requirements
Identify the key business and technical constraints
Explore alternative system solutions that satisfy the user functional requirements and constraints
Provide an evaluation and selection of a preferred systems solution and an evaluation of the impact the new system will have on the business
Specify a testing strategy which will validate that requirements have been met
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
Provides a clear Checkpoint for management approval of the project direction and deliverables
Increases the probability of success on the project through preparing, as completely as reasonably possible, the project requirements definition
Improves the customer's ability to document and approve the attributes of the solution
Improves the quality of information used by the project team to accurately estimate the project's cost and schedule
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
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.
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
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:
Develop the user functional requirements--i.e., what is to be built or delivered to the customer
Define the business and technical constraints that need to be incorporated into the project
Develop alternative system solutions that satisfy the user functional requirements and fit within the business and technical constraints
Evaluate and select a preferred systems solution
Determine the impact of the new system on the business
Specify a high-level testing strategy
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:
What does the current system do?
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:
The Project Summary Statement that was prepared in the opportunity identification phase of the project
Materials from the existing system, such as:
System Change Requests
Strategic business plans
The emphasis for data gathering in this phase is on:
Business events and how they should be handled
Interfaces to other systems
Inputs to the system
Outputs from the system
Data resources needed by the system
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:
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
Individual interviews based on a standard set of questions
Surveys that target specific information from specific customers or user groups
Focus groups that utilize current techniques for data gathering and analysis from diverse participants
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:
Business processes and procedures
Interfaces to other systems
System inputs and outputs
How the current system works
A description of current processing volumes and system performance
A description of anticipated processing volumes and desired system performance criteria
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:
Capital dollars that may have been budgeted for this project in advance
A startup schedule that has been defined or tied to another event
Policies of the business unit
Government regulations that need to be satisfied or adhered to
Prescribed operational characteristics or performance levels
Technical constraints are generally in the areas of:
Technical resource availability
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:
What business process might be eliminated?
What business process can be streamlined?
How can we improve the quality of the business's product?
How can we improve the quality of the business's service?
How can we reduce business costs?
For each view, develop alternative models of:
The automated processes
The Guide processes
Interfaces between the Guide and automated systems, as well as interfaces to other systems
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:
Business application knowledge and expertise
Technical approach or sophistication
Fit with business requirements
Quality assurance processes
Future product direction
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:
Formal or informal request for information (RFI)
Request for proposal (RFP)
Visits to the suppliers for demonstrations
On site demonstrations by the suppliers
Trade shows or seminars where as large number of suppliers are present
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:
Ongoing operating considerations
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:
Procedures and work flows
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:
Measurable functional criteria - the functional capability that must be present in the system
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.
[Project team names or Project Manager's name representing the team]
I. Management Summary
II. RDD Objectives
III. System Requirements Overview
IV. Recommended System
VI. System Displays
VII. System Constraints
VIII. Test Strategy
IX. Risk Analysis
For providing as the primary deliverable in the analysis phase
For maintaining the approved document as a file copy in the project notebook
Request for Proposal
For assembling the project estimate based on vendor inputs according to system specifications
JB Danforth Company Proprietary
"); pop.document.writeln (""); pop.document.close (); count++; }; // -->