Wednesday, December 12, 2018

Requirements definition (Reading memo)

Example documents

I read this example documents of requirements definition[1]:
And the following characteristics can be seen:
There are 4 sections in the document: Project title section, Aim of the system section, Functional requirements section, Non-functional requirements section.
Functional requirements and Non-functional requirements are separated. They are not treated as same requirements. These documents describe what features the solution, which the projects will implement, should have. But it doesn't describe the features in detail, for example, what interface the system will have, whether it is web application/desktop application or what programming language will be used. (But requirements like "Run on Windows OS" are included maybe because that is what the client requests.)

Requirements vs Specifications

Requirements specify what the product/system should/shall do. Specifications describe how the product/system is built and works. What we must make in the requirements definition process is the requirements.

Requirement definition

UC santa cruz's website says the following steps are necessary for the requirement definition[2]:
  • Define Functional Requirements
  • Define Non-Functional Requirements
  • Conduct Existing Solution Inventory and Gap Analysis
  • Specify Requirements
  • Obtain Sign-Off of Requirements
And you can see in the example documents of the previous section, those documents have both of the 1 and 2: functional and non-functional requirements. As you can see in the example documents, functional requirements are what the solution should do. The followings are citation from one of the project of the example document:
  1. Host multiple games simultaneously
  2. Users able to playing more than one game at a time
  3. Individual profiles for each user
On the other hand, non-functional requirements are additional technical requirements or requirements that should be achieved by operation/maintenance/performance of the solution. For example:
  1. Accessible to users on the internet with just a web browser
  2. Platform and browser independent client
  3. Server works with Apache Tomcat and MySQL Database
The following 5 steps are the steps which are necessary for requirements definition described in UC santa cruz's website.

1. Define functional requirements

When a team define functional requirements, you must bear in mind, that the team can not implement every feature the client requires. According to the available budget and schedule, you must adjust the requirements. To do so, you prioritize the each requirement.

This image is from "Requirements Definition"

"Must have" is a requirement you must accomplish. But "Preferred" and "Optional" are the requirements that aren't absolutely mandatory. In other word, "Must have" is a requirement we shall accomplish, and "Preferred" and "Optional" are the requirements that we should accomplish. It's nice to do this, but not essential.
Depending on the constraint of the project, the "Preferred" and "Optional" might not be implemented so that we can make sure that we finish at least all must-have functionalities within a agreed schedule.

2. Define non-functional requirements

All solutions are ideally supposed to be fast, user-friendly, useful, reliable and secure. But this is ambiguous because we don't know what will make it have the attributes. The team will identify and prioritize what makes the solution fast, user-friendly, useful, reliable and secure.
After thinking about function/non-functional requirements, also agree with the client and the team on performance requirements (example: the system must deal with 1 thousand requests per second), interface requirements (example: the screens' graphical designs) and constraints (which can not be traded off with respect to cost/schedule/perfermance).
Non-functional requirements for example:
  1. Performance requirements
  2. Constraints (cost/schedule/performance)
  3. Interface requirements (if web app, used with what browser? with what kind of interface?)
  4. Environmental requirements (in which environment, the product/software will be used? web app? desktop app? windows os? mac os?)

3. Conduct Existing Solution Inventory and Gap Analysis

Often the customers are amateurs in technology. Even if the customers think their ideas are unique idea, such ideas are often already realized in existing solutions. Check if such existing solution can be reused or not. If it can't be entirely or partially, where and what is the gap.

4. Specify Requirements

After defining functional and non-functional requirements, then conducting existing solution inventory, the team must make the specifications.
You must make sure all the requirements are fixed before the design begins. Force the stakeholder to check and consider all of the requirements because correcting poorly written requirements is easier and faster than changing the requirements after the design begins. Correcting misunderstandings in the poorly written requirements after the design or even the development begins often cause the project to fail.
Careful reviews with the client and the stakeholders can reduce misunderstandings, inconsistencies and omissions early in the development cycle.
Also provide a basis for estimating costs and schedules. All clients want a perfect product/software with perfect performance and sophisticated super-user-friendly interfaces but with low budget and short development schedule. Although it is IMPOSSIBLE.
The description as given in the requirements will be a realistic basis to estimate cost (price/bid) and schedule. We must find realistic goals and estimates based on the requirements. And agree on a possible, feasible and realistic requirements.

5. Obtain Sign-Off of Requirements

Make the contract. Ask the client for the review on the requirements.

Levels of requirements

There are levels in requirements. At first, you must decide low level requirements.
The stakeholders and the developers must agree on the functional/non-functional requirements of the product/software. But all requirements can not be decided at all once.
This is because higher level requirements can be decided only after the lower level requirements are fixed. So we must decide level 0 requirements at first, then decide level 1, 2, 3 requirements in order. Higher level requirements are decided based on the lower level requirements.

Conclusion

The document of requirements definition doesn't need to be long and in detail but it must include functional and non-functional requirements that are meeting client's needs and they shouldn't be fuzzy. Consider if the existing solutions can be reused to fulfill client's requirements, and if not, analyze why they can't be. Ask the client to review the requirements to adequately meet their demand and make sure the requirements are correct so that we don't need to revise it after the design/development begins. Then make the contract.

References

[1] "EXAMPLES OF REQUIREMENTS DEFINITION" The University of Nottingham School of Computer Science.
[2] "Requirements Definition" INFORMATION TECHNOLOGY SERVICES, UC santa cruz.
[3] MIT 16.842 Fundamentals of Systems Engineering, Fall 2015 https://www.youtube.com/watch?v=J_y2I09rj_I



Posted by at