Requirements Phase - What is needed?
What do they want?
During the requirements phase, the scope and requirements for a software project are clearly defined and documented. Business needs are discussed from many different perspectives. Be careful not to fall into the trap of gathering solutions this early in the process. The primary focus should be on what needs to be built, not how it should be built. Ask: What data? What functions? What interfaces? What constraints? If more time is spent answering these types of questions during this early phase, there will be a direct savings of effort, time and money by the end of the project.
A clearly defined scope for the project requires careful analysis of high-level requirements and project constraints like budget, target dates and the availability of resources. Discussions and negotiations to identify the flexibility of each of these are essential. The project scope is often driven by the least flexible element.
The capturing of requirements is improved by using techniques such as process scenarios, use case scenarios, and data flow diagrams, to name a few. It is important to have an established method of communicating with all stakeholders about project requirements.
Requirements analysis is a communication-intensive process. Communication with all the stakeholders of the proposed system is crucial. Developers alone cannot possibly define the complexity of contemporary business systems. Stakeholders include clients, end users, developers, and any AIS team involved during the new system’s life cycle.
The types of requirements include:- Functional and behavioral descriptions
- Data needed to provide functions
- Reporting and administrative needs
- Security needs for the system
- Production support needs
- Training needs for users
- Recovery needs for the system, for business continuity, for a disaster
What do we already have? What are others doing?
Analysis of an existing business process must be conducted along with analysis of any systems that support it. It is beneficial to conduct research about what others in the industry are doing when faced with similar requests, including their use of third-party software.
What can we do? What should we do?
The feasibility of the proposed project should be reviewed with consideration of available time and resources. Meetings with the stakeholders need to be held for the purpose of assessing possible risks and benefits.
Is it correct? What will we do?
Frequent reviews are important during this phase for achieving stakeholder consensus and support. The project scope and system functionality must be clearly understood and mutually agreed upon by all stakeholders. For example, the data administration, security, customer help center, operations control center, training, and technical support teams must all be aware of the plans at this phase.
Note: Documents produced during this phase will be used in later phases, especially during the design and testing phases.
(revised 7/7/2005)
