In this article I will how to build requirements documents.
What do Requirements mean?
A requirement is: A condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
What are the types of requirements?
BABOK has described 4 types of requirements as shown below:
- Business Requirements
- Stakeholders Requirements
- Solution Requirements
- Transition Requirements
Lets get into the definition of Business Requirements:
Business Requirements:The purpose of business requirements is to define a project’s business need, as well as the criteria of its success. Business requirements describe why a project is needed, whom it will benefit, when and where it will take place, and what standards will be used to evaluate it. Business requirement generally do not define how a project is to be implemented; the requirements of the business need do not encompass a project’s implementation details.
Functional Requirements: Functional requirements may involve calculations, technical details, data manipulation and processing, and other specific functionality that define what a system is supposed to accomplish. Behavioral requirements describe all the cases where the system uses the functional requirements, these are captured in use cases. Functional requirements are supported by non-functional requirements (also known as “quality requirements”), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). Generally, functional requirements are expressed in the form “system must do <requirement>,” while non-functional requirements take the form “system shall be <requirement>.”The plan for implementing functional requirements is detailed in the system design, whereas non-functional requirements are detailed in the system architecture.
Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs. Also known as system qualities, nonfunctional requirements are just as critical as functional Epics, Capabilities, Features, and Stories. They ensure the usability and effectiveness of the entire system. Failing to meet any one of them can result in systems that fail to satisfy internal business, user, or market needs, or that do not fulfill mandatory requirements imposed by regulatory or standards agencies. In some cases, non-compliance can cause significant legal issues (privacy, security, safety, to name a few).
In business analysis, transition requirements define any and all temporary capabilities, conditions, or activities that are necessary for moving solutions out of development and into real-world business use. They do the following: Describe what has to be done with people, process, and technology before you can get from the as-is into the to-be. Cover awareness-building, education, and training for the new way employees must work, accounting for, and outlining the differences from before to now. Define any shifting, movement, enhancement, or change to data and information out of their original structures or locations into their new data homes.
What is a Wireframe?
If you are doing Business Analysis from the UI side, wireframes become an important piece for you.
Wireframing is a way to design a website service at the structural level. A wireframe is commonly used to lay out content and functionality on a page which takes into account user needs and user journeys. Wireframes are used early in the development process to establish the basic structure of a page before visual design and content is added.
A wireframe is a layout of a web page that demonstrates what interface elements will exist on key pages. It is a critical part of the interaction design process. The aim of a wireframe is to provide a visual understanding of a page early in a project to get stakeholder and project team approval before the creative phase gets underway. Wireframes can also be used to create the global and secondary navigation to ensure the terminology and structure used for the site meets user expectations.
5 Steps To Building Requirements Documents
Let’s apply the theory mentioned above to the case study we have been working on. To recap what we have done so far click on the following articles in sequence:
So how do you build requirements documents?
To go through this exercise access the BRD and FRD template located here: https://baknowledgeshare.com/business-analysis-templates/
The first part is the document version. I know there are a bunch of ways to track the versioning now a days but work in my opinion is the best way to track changes.
The next few parts oft he document are as follows. Include who the stakeholders are in the document and who needs to sign off on this document
The next section is Project Summary and the References. The project Summary in my opinion is an important section. This gives anyone a window into what this project is all about. Include any documents you may have referenced to build this requirements spec in section 1.2.
The next section covers assumption, dependencies and constraints that are very specific to the requirements process. These are not Project level assumptions, dependencies and constraints, though they could cross over.
The next few sections are the Glossary – This is a good habit to build a glossary of terminology. The decision log section will track any open items that need to be addresses for the requirements. The Process flow and architecture could include either a context diagram, an actual flow of the user process.
The next section is the models sections where you will include any supporting documentation. In this case study you would want to include the wire frames.
In summary
You saw the different sections of the requirements document and How To Build Requirements Documents.
How do you build your requirements documents?
