Requirements Overview
Include this section in a detailed requirements document to provide a high-level summary of what is trying to be achieved.
Scope
Definition of the areas that have been included the analysis and those that have been specifically excluded.
This may include organisational areas, processes, customer types/segments, systems, business locations.
Where out-of-scope items may be contentious, state reasons for exclusion.
Requirements Definition
Details of the functional requirements to be delivered.
You may be using a process-driven approach or a tabular listing of requirements. Whichever approach, it should be clearly stated whether each requirement is mandatory, optional or nice-to-have. Or, use whatever classifications have been agreed within your project
If using a process driven approach then non-functional requirements (below) may need to be related to each process. Otherwise sections 8 to 11 will be required to state the non-functional requirements.
Sections 8 11 may not be required for a high-level requirements document and some may not be required where there are no systems components to the project.
Process maps
Add or link to process maps here
Constraints
Include details of any imposed constraints on the requirements. For example, where it is known that integration into an existing system cannot be achieved or there are externally imposed time constraints. State reasons for constraints such as legal or regulatory.
Location/User Groups
Details of the user groups affected by the change or who will be using new functionality. Include details of known locations for each user group and the number of users in each location.
Security Requirements
Details of any security requirements such as supervisory access, or how access should be prevented to non-authorised users. Do not include requirements which are already defined generically for the organisation in question.
Service Level Requirements
Details of the required availability of a proposed system (e.g. 24 hours, 365 days per year) and the level of resilience required (e.g. maximum downtime = 1 hour per month). Include details of required response times but only where there is a specific need not covered by the organisations generic rules.
Volumes
Include details of average and peak volumes across all processes/transactions and any anticipated growth in these volumes. State clearly when any peaks occur.
Dependencies
Details of any external event, task or project which has a material influence on delivery of these requirements.
The following further sections may be required depending on the nature of the project and the level of requirements being defined. You may choose to include them as appendices or within the main body of the document.
Data Model
Likely to include an Entity Relationship Diagram and entity descriptions
Data Conversion Requirements
Required where data is to be converted/migrated from an existing set of processes whether manual or automated.
SIMPLE FORMAT FOR REQUIREMENTS
| Ref | Description | Who Raised | MSCW | Accept or Reject | Success Criteria |
| Item Name /Title | Item Description | Owner/Customer | Must Have, Should Have, Could Have | YES or NO | Detail of specification / criteria |
| Item Name /Title | Item Description | Owner/Customer | Must Have, Should Have, Could Have | YES or NO | Detail of specification / criteria |
| Item Name /Title | Item Description | Owner/Customer | Must Have, Should Have, Could Have | YES or NO | Detail of specification / criteria |
| Item Name /Title | Item Description | Owner/Customer | Must Have, Should Have, Could Have | YES or NO | Detail of specification / criteria |
COMPLEX FORMAT FOR REQUIREMENTS
Functional Requirements
IP Outsourcing Key Requirements
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
User Interface
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Alerts and Warnings
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Maintenance Interface
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Customisation
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Reporting
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Security and Control
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Interface
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Non Functional Requirements
Availability
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Performance
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Security
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Data Storage, Backups and Recovery
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Supportability
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Scalability
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
Legal
| Ref | Description | Who Raised | M S C W | Accept or Reject | Success Criteria |
TYPICAL FORMAT FOR USER STORIES
Note in Agile we dont know exactly how long things take so instead of dates and a schedule we use Points to estimate effort
01 Quick to deliver and minimal complexity. An hour
02 Quick to deliver and some complexity. Multiple hours
03 Moderate time to deliver, moderate complexity, possible unknowns
05 Longer time to deliver, high complexity, likely unknowns
08 Long time to deliver, high complexity, critical unknowns
13 Long time to delivery, high complexity, many critical unknowns
21 Youre doing this wrong.
| As a | I want | So that | Best product | Best Approach | Effort |
| Role/Person/Function | The function /ability or feature | The outcome / benefit / utility | What the 'thing' would be | How this might be done | Pts 3-5 |
| Role/Person/Function | The function /ability or feature | The outcome / benefit / utility | What the 'thing' would be | How this might be done | Pts 3-6 |
| Role/Person/Function | The function /ability or feature | The outcome / benefit / utility | What the 'thing' would be | How this might be done | Pts 3-7 |
| Role/Person/Function | The function /ability or feature | The outcome / benefit / utility | What the 'thing' would be | How this might be done | Pts 3-8 |
| Role/Person/Function | The function /ability or feature | The outcome / benefit / utility | What the 'thing' would be | How this might be done | Pts 3-9 |
| Service Desk User | To understand the ROLE / RESP/ TASKS to be done on daily,weekly, monthly | Do my work and succeed against agreed SMART goals | Job Descrip. | One-to-One Meet | Pts 1-2 |
USEFUL REFERENCES
https://www.scalablepath.com/blog/agile-points-explained-fibonacci-sequence/
