In the hurry to achieve speed, I fear, we are missing the basic picture on requirements and their fundamentals. If my fear is true, this will impact us more dearly. In this post, I shall be discussing what is a requirement, requirement types and their relational structure.
I. What is a requirement? - A requirement is condition or capability needed by a user to solve a problem or achieve an objective. It is a condition or capability that must be met or possessed by a system or system components to satisfy a contract, standard, specification or other formally imposed documents.
II. Requirement Types - Requirements are broadly classified into two major heads. They are functional requirements and non-functional requirements. Functional and non-functional requirements can further be classified into further sub heads. Below figure illustrates the relationship of these several types of requirements information.
II.A. Functional requirements
- Business requirements describe “why” the organization is implementing the system. It describes product sponsor's high level objectives. These are stored in “vision and scope document”, sometimes called as “project charter” or “market requirements document”.
- User requirements describe “what” the user will be able to do with the system. It describes what the user will be able to do with the product such as goals or tasks that user must be able to perform. Use cases, scenarios, user stories and even-response tables are some ways to represent User requirements. If you are developing use cases, you might store them in a “use-case document”.
- Functional requirements describe software functionality to be built in the product each as a “value” to the user. These are behavioral requirements. These contain traditional “shall” statements that describe what the system “shall do” or what the system shall let the user to do. These are stored in “Software Requirement Specification document”. Specifying correct set of functionality enables the developers to achieve their tasks/goals, thereby satisfying the business requirements.
- System Requirements describe interface requirements for the proposed product so that it can conform to, and communicate with other external sub systems (can be software, hardware, people etc). For example, while developing payroll application, it should be able to communicate with other subsystems like HR system.
II.B. Non-functional requirements
- Business rules dictate capabilities that system must possess to adhere to the rules. These include corporate policies, government regulations, industry standards, security constraints and computational algorithms. These are practiced across the enterprise product family breadth and therefore system need to comply with these without fail.
- Quality attributes represent product characteristics like performance, reliability, scalability, availability, maintainability, security, extensibility, manageability, security and other service requirements.
- Performance represent (1) Response time in seconds for a screen transaction per user (2) Throughput - number of transactions per a second. Examples can be (A) No more than 3 seconds per screen (B) one hundred transactions in a second.
- Reliability/Stress - It deals with "accuracy". Reliability ensures the integrity and consistency if the applicaiton. As the load increases on your system, your system must continue to process or handle transactions as "accurate" as it did before the load was increased.
- Scalability - A system is considered scalable if, as the load increases, the system still responds within acceptable response limits. To understand scalability, you must first understand the capacity of the system, which is defined as maximum number of users or processes or transactions, a system can handle and still maintain the quality of the services. We can achieve scalability in two ways. (1) Horizontal Scaling - Adding further web servers, app services to the existing servers (2) Vertical Scaling - It involves adding additional processes, memory, disks to the current web services, application servers, database etc. Thus, the proposed architecture of the product must be able to handle the vertical or horizantal scaling of the hardware
- Availability -It deals with accessibility of the proposed system. It ensures that a service/ resource is always accessible
- Extensibility is the ability to add additional functionality or modify existing functionality without impacting other components of existing system
- Maintainability - It is the ability to correct defects within the existing functionality without impacting other components of the system.
- Security - It ensures that the system cannot be compromised by ensuring:
- Physical Security - It addresses the issues relating to data theft, Vandalism etc.
- Network Security - It addresses the issues relating to data encryption, decryption etc.
- Domain Security - It addresses the issues relating to corporate domain network, active directory, user administration etc.
- Server Security - It addresses the issues relating to role based or application based administration etc
- Manageability - It ensures continued health of the system with respect to performance, reliability, availability, extensibility and security
- External Interface requirements describe external interface design implementation capabilities between the system and the outside world. Thus, these talk about how our proposed product will fit into it's echo system.
- Constraints impose restrictions on the choices available to the developer for design and construction of the product.
III. What Requirements Are Not - Requirement specifications do not include design or implementation details (other than known constraints), project planning information or testing information.