The requirements process is an extremely important part and hence we need to understand what needs to happen here before we go into the different project knowledge areas.
Some important notes about requirements
- Requirements need to be prioritized
Before the project starts agree what document you want to use for the HIGH LEVEL requirements. It
might be helpful to gather this info on a spreadsheet.
- The number of requirements needs to be controlled. If you have more requirements than you can
handle set a challenging but realistic requirements threshold.
If you have a set timeline by your project sponsor keep in mind how much development time you have and
what is most important to your project sponsor.
- Remove duplicate requirements as early as possible to ensure less confusion
this needs to be done during the HIGH LEVEL requirements gathering in order to prevent confusion
- Ensure volume and performance requirements are clearly stated
How many people, processes etc will use your solution? Clarify this as early as possible so that you provide
the best possible design for the desired solution
- Set timelines for the requirements process and stick to it (e.g. set a requirements submission deadline)
It's simply a good planning practice. Don't forget to add some slack.
- Keep the requirements document under version control
This ensures that every stakeholder understands what is in and what is out of scope. Requires a thorough
communication plan.
- Once the submission deadline has passed implement a change management process to handle
additional requirements (new requirement submissions or changes to existing requirements)
This ensures that the scope change fits within the time and budget expectations (if it is done
properly)
- Ensure stakeholders have access to requirements
- Do you need any internationalization (translation) for your project? If yes, have all requirements
been clearly documented?
Ensure that you have test cases for all internationalization related functionality. This could be a translation or
a different system behavior in another country, sub-region or region
- Ensure all Hardware, Software and communication interfaces have been clearly defined
This is one of the Key points since the interfaces tend to cause the most issues.
- You should be able to create a use case / test case for every functionality that you develop or plan
to use
Here some good articles on the requirements topic from Karl Wiegers
The Requirements Document should contain these area's
System Overview
1. Overview
* Analysis
* Assumptions, Risks, Dependencies
* Estimated work, cost
2. Scope Requirements
* end-to-end business flow
* Workflow + System Diagrams
* Impact Analysis, System contacts
3. Business Requirements
4. Functional Design
5. Data Conversion Requirements
System Design
1. Data Flow Diagram
2. Data Model
3. Integration requirements (e.g. includes Interfaces)
4. System Process (Input, Process, Output)
5. Error Handling
6. Security requirements
7. System scalability
8. Performance requirements
1. System Performance Requirements
2. Use Cases for Testing
3. Test Plan
4. Issue Handling
The next post will on November 21 and then we go into the different project knowledge areas.
