The analysis stage refers to determining the requirements that solve a need or opportunity. This stage involves 3 activities:
Requirements
Functional requirements
Function requirements refer to the capabilities of your solution.
- What does it do?
- What does it need to do? Quite simply, functional requirements are essentially what your solution is doing.
For example, this could be:
- your solution may receive data and does a calculation to it.
- your solution may receive data and manipulates it.
Functional requirements can also be really specific, even to a certain field:
- Field 1 only accepts numeric data.
Non-functional requirements
Non-functional requirements refer to requirements that aren’t about what the solution does. This is why it is also known as quality requirements, as it isn’t about what the solution does, but more so what the solution is.
To determine non-functional requirements, the following is a table of non-functional requirements.
| Requirement | Description |
|---|---|
| Usability | How easy it is to use your users to use your solution. |
| Reliability | How reliable/able your solution is at doing your proposed functional requirements. |
| Performance | Response time, throughput, availability, accuracy, etc. The attributes of the system. |
| Supportability | How ‘scalable’ your solution is. |
| Adaptability | How able your solution is at dealing with different issues and concepts. |
| Maintainability | How easily can you fix defects or implement new technology. |
| Robustness | How well can your solution handle failures? |
| Speed | Response time, processes, etc. |
| Size | How big will your solution be? |
Constraints
Constraints describes the conditions or limitations of your solution. The follow are constraints that need to be addressed:
| Constraints | Description |
|---|---|
| Economic | This refers to the cost and time of your project. Deadlines and your budget for example will for under economic constraint. |
| Technical | Speed or processing, equipment availability, compatibility with devices and technologies, security, etc. |
| Legal | Intellectual property, ownership of data, privacy, etc. |
| Usability | Ease of use, accessibility, usefulness |
| Social | Culture, ethnicity, age, education - what must you consider when designing your solution? |
Warning
Don’t get confused between requirement and constraint! Whereas a requirement is a criteria (something that you must manage in developing), a constraint is more like a limit - something that is stopping you from doing normal work.
For example, the system must not allow more than 10 users at a time is a requirement as that is a design choice (something you implement) whereas the program file size must not exceed 125 kilobytes is a constraint because it is a restriction.
Scope
A solution’s scope refers to the boundaries of what the solution is doing.
Essentially, you need to describe:
- What your solution is doing; Goals, objectives and benefits.
- What your solution needs; capabilities (databases? upload?)
- Specific features? Functions?
- Potential impact on users
and importantly, what your solution doesn’t do. This reduces scope creep and allows you to focus on your solution’s requirements.
Keyword!
A scope creep refers to uncontrolled expansion of a project. This means that you’re going to be adding more requirements than you initially started with, resulting in more work and potentially tightening constraints.
By having a good initial scope alongside a strong idea of your solution in mind, you can avoid scope creep and reduce the work you will need to accomplish when designing.
Versioning
Alongside a solution’s scope, you should also think about versioning. When are you able to create a minimum viable product (MVP)? If so, which requirements have you fulfilled? What hasn’t been fulfilled?
The SRS document
The final output of the analysis stage would be a document containing all the findings called a software requirements specification (SRS).
The software requirements specification (SRS) document should include the following information:
- purpose of the SRS
- intended audience characteristics (end users)
- technical environment characteristics (operating environment)
- scope of the solution
- constraints
- functional requirements
- non-functional requirements
- use case diagrams
- context diagrams
- data flow diagrams.
Requirements
The SRS should be:
- Realistic - the system can be implemented within constraints.
- Verifiable - once built, repeatable tests can be designed to demonstrate the SRS.
- Traceable - each requirement can be traced through development.