Most projects, particularly system development projects, are not fully defined when they are authorized. The client's wants, needs, and requirements must be articulated and documented somewhat quickly, albeit with minimal detail. Then, during the early phases of the project, this documented information must be reconciled with current technological capabilities. In these projects, there is a continuous dialogue between the project team and the client with regard to the attributes of the deliverable . During, and as a result of, these frequent dialogues , the team continually embellishes the then current and well-defined features of the deliverable. The enhancement of the details of the deliverable will reflect the requirements of the user as well as business needs of the client. The client may be represented by a number of different groups that typically include management, system owners , users, customers, developers, and designers. Each stakeholder will have a unique set of interests that must be met in the outcome of the project. Ironically, sometimes these stakeholders might have conflicting interests, requirements, and issues.
The requirements and needs of the client are articulated in a set of documents that will in turn provide the basis for the mission of the project. In essence, a nondescript problem must be turned into a well-defined problem by virtue of a detailed set of requirements. To the extent possible, the definition of requirements must be as accurate as practicable, because information obtained during the requirements definition process will be used to determine whether or not the project should be authorized. Later, as additional information becomes available, the updated set of requirements will be used to determine whether the project should continue or whether cancellation of the project should be recommended.
It is very common for a client to modify the expression of requirements as the ramifications of those requirements are manifested in the definition of the features of the deliverable. Parenthetically, the dynamic nature of this process is one of the reasons for relatively large cost and schedule variances in system development and systems integration projects. The volatility of cost and schedule will become even more significant when the project uses novel technologies in responding to the client's evolving business needs. Notwithstanding, a project charter similar to that in Appendix 2A must be developed in order to document the evolution of the mission of the project team.
A methodical requirements management process will begin with exploratory exercises in order to fully understand the client's needs. The next step involves the development of a clear and concise statement of the problem. The narrative description of the problem is then expanded into a detailed technical specification of the requirements and functions. The technical specifications, and their companion suite of tests, will define the attributes that verify the attainment of the services and/or products that would meet the originally stated problem of the client. Naturally, the specifications and tests will be reviewed by the client to validate the problem and its solution. Finally, an ideal requirements development process must produce several alternative solutions, allowing the client to explore the advantages and disadvantages of each one.
A properly executed requirements management task will start with the articulation of the client's needs, to the extent possible (Figure 2.7). The key is to document these requirements with as much quantified detail as possible. Care should be taken to identify all primary and secondary requirements of the intended product. Such specificity will help the client verify each of the requirements statements in an informed fashion. Beyond that, an effective requirements management process will allow the team to craft the deliverables in full compliance with the client's current needs and requirements. It is at this point that alternative solutions and acceptance testing schema for each solution are formulated. Once the project moves into the implementation phase, a clear set of specifications must be drafted and/or finalized. Clarity of project objectives will facilitate the usually arduous tasks of risk management, configuration management, and cost/schedule management.
Gather Stakeholder Information
Define Deliverable Attributes
Formulate Project Cost and Duration
Develop Acceptance Testing Schema
Devise Alternative Approaches
It is important to note that project information exchange for the vast majority of traditional projects is conducted through meetings between the project team and the client. Some of the useful tools of the requirements management process are interviews with stakeholders, customer involvement workshops, simulations, usability studies, and prototyping. All of these tools involve some type of personal interaction. Customer involvement workshops promote contact between developers and users and help many different users become part of the process. Sometimes simulations define selected project processes by bringing users together to collectively work on a problem. Usability studies can provide direct evidence of the ease of use of a product and thus can help uncover common errors or faulty design. Finally, prototyping can provide input for the requirements identification process by prompting direct user influence and direct feedback concerning requirements. Most, if not all, of these tools use face-to-face meetings on traditional projects. By comparison, such meetings need to be conducted through alternate means for virtual teams . These alternate means will have to be fully formalized and continually enhanced. The exact nature of the alternate information exchange modes is dependent on the organization, although many of them will have roots in the web, e-mail, and Internet messaging.
Once the initial requirements have been articulated and documented, then a baseline estimate for cost and schedule will be formulated in light of those requirements. Then, as the project progresses into implementation, requirements management activities include those tasks that are performed in order to keep a reasonable balance among the project's triple constraints. The continuing requirements management task must react to changes in any of the triple constraints. The objective of a midstream change in the project is, or should be, that the client ultimately takes delivery of a product that serves all of its reasonable business needs. The mission of the project manager is to do this while maintaining acceptable values for the project's cost and schedule. Maintaining this balance is a highly delicate task because most changes in requirements cause an increase in cost and a delay in the delivery date. The situation might be more complicated if the delivery date is somewhat inflexible , in which case the only one of the triple constraints over which the project manager has any real control is the project cost.