Today we focus on the Requirements Analysis stage of the SDLC.
The input for this stage of the SDLC are the business needs recommended in the Feasibility Study.
This stage of the SDLC is about working out exactly what needs to be built or purchased in order to deliver the business impacts and benefits defined in the Feasibility Study.
There are a number of roles involved this stage that we should be familiar with.
| Role | Responsibility |
|---|---|
| Project Sponsor (customer) | Owns the project and is accountable to the organisation for delivery of business benefits (feasibility study). Controls the scope of the project |
| Managers | Own specific requirements |
| Users | People who use the current system and will use the new system. Important they they buy into the new solution |
| Domain Experts | Experience in working in the domain |
| Project Manager | Responsible for development and deliverable to the Project Sponsor |
| Business Analysts | Elicit, document and analyse requirements |
| Testers | Help validate that requirements are testable |
| Developers | Help validate that requirements are clearly defined |
Usually we think about customers as external to an organisation. For example when we buy something from JD sports, we are the customer. However in the roles above you can think of the Project Sponsor as a customer. They will ultimately receive the final product even though they may not use the product themselves, their team may end up using the product.
"Requirements are not just waiting to be picked from people like apples from a tree. They have to be mined like tin or iron" Developing Information Systems by James Cadle
It’s the Business Analysts that will go into an organisation and elicit requirements. How do they do this?
For example, a Business Analyst might look at a user inputting data in a form and ask questions such as:
All of the methods described above involve talking to people. There are also others approaches that are more data driven.
As an example, imagine you are a Business Analyst working on a project to automate manual processes in a leisure centre. You could use activity sampling to understand what those manual processes were. By visiting the leisure centre at different times (to generate a fair sample) and recording what the receptionist is doing you gather your requirements. For example:
Requirements analysis elicits both functional and non-functional requirements.
Functional requirements describe how a system should work
| ID | Priority | Description |
|---|---|---|
| FR1 | MUST | Menu options include vegetarian, vegan and calorie controlled choices |
| FR2 | MUST | Allergen information is displayed against each ingredient |
| FR3 | MUST | The password reset email contains a unique link which expires after one hour |
| FR4 | SHOULD | Payment options include ApplePay |
Non-functional requirements describe the constraints on the system such as system availability, conformance to security standards etc. Some examples are listed below but take time to study a more complete list on Wikipedia
| ID | Priority | Description |
|---|---|---|
| NFR1 | MUST | The home page loads fast |
| NFR2 | MUST | The system supports many concurrent users |
| NFR3 | MUST | Data is held securely |
Requirements can also be categorised further into:
| Category | Description |
|---|---|
| Business requirements | General requirements high-level statements |
| Stakeholder requirements | Statements for the needs of individuals |
| Solution requirements | Detailed technical requirements (i.e. database must handle 2,000 concurrent connections) |
| Transition requirements | What is required to go from state A to state B (training, recruitment, processes, re-structuring) |
There is quite an art to form a good requirement. Below are the main qualities your requirement must have:
Let's look at some examples of good and poor requirements in terms of how "complete" and "unambiguous" they are:
| Poor | Good |
|---|---|
| The system must be useable | The system must conform to the Nielson Top 10 Usability Heuristics |
| The system must be well tested | All code must have 80% test coverage |
TASK - Imagine you are creating a food delivery service called "SOFresh". Create a set of functional and non-functional requirements to express the requirements for the site. Use the ones above as a starting point.
Functional decomposition is the analysis of complex systems/requirements by breaking them down into smaller, simpler elements.
Requirements can be expressed in a number of different forms including:
UML Use Case diagrams which show the interactions between the Actors and the system
UML Activity diagrams which show how activities are co-ordinated
Personas - ficticious characters which represent the different types of actors that will use a product
User Stories which describe a feature from the perspective of the end user
The output of this stage is a requirements document.
A requirements document should include a Glossary of Terms which explains acronyms or domain specific words used within the document.
It should also include a Data Dictionary which lists data requirements in such a way that in the Design phase it will be easy able to design a relational database or data structure. Here is an example Data Dictionary
Here are some examples of real requirements documents:
Patient Level Contract Monitoring (PLCM): Requirements Specification
Requirements document for new web-based sales system for Solar Based Energy Inc.
Using the Persona template provided by your coach, describe the bios, needs and challenges of at least 3 ficticious users of the SoFresh system
Using the User Story template provided by your coach, describe at least 3 stories which provide value to users of the SoFresh system
Create a UML Use Case Diagram to represent the interactions between the Actors in the SoFresh system
Create a UML Activity Diagram to model an automated chatbot responding to a customer query
Commit your code to GitHub and send a link to your coach for review.
Requirements
| Functional | Non-functional |
|---|---|
| XXX | YYY |
Video - Functional and non-functional requirements explained
