Manage Project Requirements Analysis and Design
Ensure Software Requirements are Right so Design Works as Wanted
Jan 1, 2009
Project managers will have planned for the project requirements phase to be followed by analysis and design and then implementation. However, this is also a time when many projects go wrong resulting in project failure. A key reason for this failure is that people have been unable to either clearly identify or specify requirements with the result that the analysis and design phase either takes much longer than expected or produces the wrong result.
General Types of Requirements
Requirements as a term is used generally to cover a number of levels of detail and consequently the naming convention used can be different:
- Business Requirements - concerned with the business impact of a solution, cost benefit analysis and integration within the general business environment
- Business User Requirements - expected business usage of the solution and its key characteristics
- System [Non-Functional] Requirements] - expected operation of the solution covering all of the different non-functional areas and expectations covering things like interfaces, availability, performance, backup and restoration...
- Functional Requirement - detailed requirements of functionality expected, in particular user functions and user interaction
Generically these can all be referred to as project requirements and for technology solutions software requirements.
Software Requirements
Defining good software requirements is not easy and writing better requirements requires some work. The initial set should be derived from project initiation and the project proceeds from there to develop them further. Each requirement must be:
- Clearly stated and unambiguous - avoiding unclear or general statements
- Specify only one thing - avoiding a requirement that covers many different things and perhaps does not cover any of them very well
- Be testable, a test case can be written that can test that this requirement has been implemented - avoiding vague or unclear requirements
If the software requirements have been produced with this due care and attention then they become documented into a requirements specification document.
Requirements Analysis
The requirements specification document should be considered a draft document that becomes the subject of a requirements analysis. The purpose of that analysis is to ensure that the requirements are cohesive, state completely and accurately what is required and do not have duplicates or conflicting requirements. Completion of this work will have gone a long way to producing a good requirements specification. A waterfall project management approach would now be finished and move onto the next phase and an iterative approach would consider this completion of the first iteration of requirements, with subsequent iterations adding, changing or deleting these requirements.
Analysis and Design
Clear, complete and accurate software requirements are critical to analysis and design. Having a good requirements specification will ensure that the output of the design phase is very likely to be what is wanted. Of course, practical implementation details may need requirements to be changed but with this firm foundation and effective management of changes it should be straightforward and give the right result. This result is then tested to confirm that the requirements are indeed met by the design.
Manage Project Requirements
The key to the right result is to actively manage project requirements and ensure that they are right. The analysis and systems design phase tends to be easy if the requirements are clear. The only likely problems to emerge are practical limitations and the consequent need to change the requirements to reflect what is actually possible. As long as these changes are controlled and managed then this phase should not result in any surprises. Whilst this does not mean that a successful project is assured it is another step in the right direction.
 |
 |
 |
