We collect product requirements during a project’s requirements phase. We distinguish two main types of product requirements: enhancements to existing products, and entirely new products.
Enhancements
We classify any modification or change to an existing software product as an enhancement. This includes any change in the scope of functionality supported by the current (or contractually defined) version of the software.
Enhancements include both minor and major changes. Major changes can be completely new functions or processes within existing modules, while minor changes might be adjustments to existing features.
Major changes tend to focus on supported processes and data flows, while minor changes tend to focus on user interface features, such as data entry fields, buttons and shortcuts.
New Products
We classify as new products both new applications that we build from scratch. These include both standalone applications, as well as new modules of an existing system that contains its own set of features, functions, and behavior.
From time to time, enhancement requests lead to the development of new products. This happens when a change request requires more than an improvement in an existing part of the system, but rather an entirely new functionality.
In such cases, that functionality is scoped as a new product, and we apply all of the development steps we use for new products, from requirements scoping and analysis to product design, implementation, integration, validation and release.
How We Process Requirements
We use a system called “Gemini” for all of our project management. Gemini is a web-based, third-party application for requirement and planning. It offers comprehensive ticketing and issue management features, and allows us to collect and process all types of requests from our customers and partners, as well as within D3S internally.
We divide Gemini into projects, one for each customer, and one for each of D3S’s internal projects. We create separate Gemini issues for each requirement, where we classify them according to their type, dependencies, and priority. Gemini automatically assigns each issue a unique number (ticket ID), which we use to track development progress.
How We Structure Requirements
Whether a requirement stems from market demands, business needs, customer requests, technological advances, legal/regulatory changes, or social changes, it ultimately needs to be translated into a task we can perform.
When formulated properly, requirements are:
- Cohesive (specifies only one thing at a time)Complete (self-contained, defining all situations that can be encountered and the appropriate response for each)
- Consistent (should not contradict other requirements and should not be repeated elsewhere
- Correct (mistakes in a requirement definition will result in a defective solution)
- Feasible (must be possible given system and project constraints)
- Mandatory (although requirements can have relative priority, they must all be “required”)
- Modifiable (if a change to a requirement is necessary, it should be expressed such that it is traceable)
- Unambiguous (avoid words like “more”, “less”, “fast”, “slow”)
- Testable (should be possible to design a test to determine if requirement has been met)
Types of Requirements
Requirements need to be clearly defined before we can analyse them. The main types of requirements include:
- Business requirements (provides a high-level, measurable statements of goals)
- Stakeholder requirements (states the needs or particular stakeholder or class of stakeholders)
- Solution Requirements (describes the characteristics of a solution, including functional and non-functional requirements)
- Transition requirements (describes what’s needed to transition from an old to a new system)
Project Vision
Requirements scoping starts with the project vision. The project vision expresses the purpose of the project. It provides a framework through which we understand the intention and needs.
The project vision is typically formulated as a list of statements. These statements summarize both the high-level business requirements (i.e. measurable statements of goals), as well as stakeholder requirements (statements of the needs of particular stakeholder or class of stakeholders).
Since requirements have many different sources, we work with customers to translate these statements into concrete, deliverable goals. When creating new products, we express these goals within a detailed User Requirements Specification. For enhancements, we may produce a Simplified Requirement Specification instead.
User Requirements Specification
The User Requirements Specification provides a detailed list of all the customer’s concrete needs. These details remove uncertainty as to how a system or application will accomplish its specific goals.
The URS includes all types of requirements but focuses in specific detail on the Solution Requirements. Solution Requirements describe the specific features and functions of a software product. And it breaks these down into two main categories:
- Functional Requirements (describing the behavior of the solution, as well as the information the solution will manage)
- Non-Functional Requirements (describing the environmental conditions under which the solution must remain effective, as well as the qualities the system must have – speed, security, availability, etc.)
The URS also describes the Transition Requirements. Transition requirements specify the capabilities needed to facilitate the transition from the current, actual state to a desired future state. Typically, this means managing the migration of data and users from an old system to a new system.
Since new systems often introduce new processes as well as new features and functions, transition requirements cover everything from data conversion to skill gaps and training. For this reason, a URS includes details current business processes.
Documenting the specification can be very complex. We provide clarity by including use case diagrams, which describe each operation a user might perform within the system, as well as data flow diagrams, which describe the data model and how information will flow from one part of the system to another.
Simplified Requirements Specification
An SRS is used exclusively for enhancements, and specifically for minor changes to an existing product. Because its scope is more limited, it focuses specifically on the Functional, Non-Functional, and Transition Requirements relevant to the change. High-level statements aren’t needed, in such cases, as the change typically falls within the scope of the existing project (and product) vision.
