Requirements can be recorded in a document, spreadsheet, or database and may vary in complexity. Regardless of the vehicle, remember all requirements must be clear and concise. Abusiness requirements template has been provided for the build-out of the requirements for your project.

I am working on an on-site childcare. I am kind of lost.

. Risk Analysis

Risks will be described in this section. Risk is some uncertainty that may have an impact on the project either positively (opportunities) or negatively (threats). Risks are supposed to be analyzed as the project progresses. As risk is associated with the future, include likelihood of the risk event happening along with the impact the risk will create on the projectand of course the strategy for handling the risk. Strategies could be:

• Avoid/Enhance
• Mitigate/Exploit
• Transfer/Share
• Accept

Types of Risk

• Technological Risks: New technology issues that could have an impact on the project is provided in this sub-section.
• Skill Risks:Risk of not getting the staff with the required expertise will be elaborated in this sub-section.
• Political Risks:Political forces that could have an impact on the project are identified in this sub-section.
• Business Risks:This sub-section will describe the implications that would be created on the business either due to implementation of the project or due to non-implementation of the project.
• Resource Risks:Risks that come up due to not getting the required resources or not getting the resources on time is determined in this sub-section. Resources could be human, material, equipment or facility.
• Requirements Risks:Incorrect capture of the requirements is detailed in this sub-section.
• Other Risks:Any other risks not covered under the relevant sub-sections are captured here.

Note: The sub-sections can be changed as appropriate depending on the project.

6. Schedule

Target Date	Area of Requirement	Responsibility	Status	Revised Date (If not completed on the planned date)

7.Business Use Cases

This section will be completed with the changes involved in the business processes. For every change in the business process, a business use case will be required. There should be a justification for the revision in the business process.

Business use-case diagrams:Involvement of stakeholders in every business process (existing and revised) is described in business use-case diagrams.

Business use-case descriptions:Every business case is to be described with a text and a diagram. Template for the use-case description is provided separately.

Use Cases will be described in the following ways:

1. Brief of the use case: brief description, important flows and outputs
2. Objectives: what will be achieved due to this use case
3. Actors
4. Precedence: events that trigger this use case and the prerequisites (conditions that are to be satisfied for the use case to begin)
5. Post-conditions: seen from the angle of what happens when the use case ends successfully and what happens when the use case ends in failure
6. Priority
7. Status
8. Special requirements
9. Assumptions
10. Prompts/Business Rules
11. External Interfaces
12. Required Documents

Actors:Describe the people/organization who participate in the business processes that interact with the business as well as the system.

Internal Stakeholders:List out the internal stakeholders who act within the business or interact with the system

External Stakeholders:List out the external stakeholders (customers/vendors) who interact with the business

This table can be used to track the stakeholders/actors for each of the business process:

Name of Stakeholder	Entity	Internal/External	Business Impact

System/Processes:The computer systems/processes that will potentially affect the project or be affected by the project are listed below:

Role Map:The roles played by the actors that interact with the processes/system.

8.User/Business Requirements

This section describes the requirements from the user perspective.

System/Business use-case diagrams:Description of which users use which portion of the process/system and the interaction with the use cases.

System/Business use-case descriptions:During the initial stages of the project, only brief descriptions will be provided. As the project progresses, more information is received and the description becomes more detailed.

Requirement Categories:

Functional (F)	Requirements describing a functional or business requirement in the subject system
Interface (I)	Details up and downstream integration with other systems and applications
Quality (Q)	Requirements describing usability, performance, or scalability standards associated with the expected functionality
Security (S)	Specifies any requirements related to security and user administration.
Workflow (W)	Defines workflow or automation requirements

Requirement Priority Levels:

Essential	Requirement is essential to project/initiative.
Critical	Requirement is critical to project and should be met if at all possible.
Significant	Requirement provides a significant benefit to the business if met in project.
Beneficial	Requirement is nice to have and will be beneficial to the business.

No.	Requirement Type	Requirement Description	Priority Level	Business Impact

9.Non-Functional Requirements

The non-functional requirements not forming part of use-case documentation will be elaborated in this section:

1. Performance Requirements
2. Stress Requirements
3. Response Time Requirements
4. Usability Requirements
5. Security Requirements
6. Volume and Storage Requirements
7. Configuration Requirements
8. Compatibility Requirements
9. Reliability Requirements
10. Backup/Recovery Requirements
11. Training Requirements

Note: The level to which non-functional requirements are to be documented will depend on the type of the project.

10. Business Rules

The list of business rules that are to be in place is to be detailed.

11.Test Plan

Testing is to be standardized, and this requires a clear test plan to be developed. Every project is unique; however, the following will be a guideline:

1. Functional requirements-based testing
2. Non-functional requirements-based testing
3. Integration testing
4. Acceptance criteria-based testing