“I am so proud I made the cricket ball for client to play”- the excited developer said
“But you were supposed to design the Globe for me to study Geography” – the frustrated client replied
These kinds of conversations are common at places where the subject of Requirements Engineering does not exist. One more example being the following:
There is a quote by John von Neumann that states “There’s no sense being exact about something if you don’t even know what you’re talking about.”
Development without Requirements Engineering is like wandering, you can never be sure if you will reach the intended destination or not. Requirements Engineering is the whole process of gathering, analyzing, checking feasibility, validating and documenting the services that should definitely be present in the delivered system. Sources of information can be any previous documentation or stakeholder’s viewpoints.
It is not a sequential process, which is carried out once in a particular order. Rather it’s a process in which activities are interrelated and repeated.
WHY REQUIREMENTS ENGINEERING?
“I want something circular or elliptical” – Stakeholder (They might not know what exactly they need)
I want something “Globastic” – Stakeholder (They might use some of their own strange terms)
Moreover:
- If the customer is a group, each one of them could have their own viewpoint.
- As the product evolves, many factors might keep impacting the system requirements
Quality is the utmost important aspect of software development and to deliver high-quality software, it is essential to have high-quality requirements.
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to go rectify later”, says Fredrick P. Brooks, Jr. in his book.
This is where Requirements Engineering comes up as a boon.
HOW TO ENGINEER REQUIREMENTS?
Requirements Engineering can be reckoned with by following three basic principles of it.
1) Viewpoints
This principle states to understand the viewpoints of the stakeholders before specifying the requirements. We need to understand what are the actual problems of stakeholders or their business. There are two key tools to cover Viewpoints viz.:
a) Requirements Gathering – Gathering essentially means to collect the piece of information that is available.
This may include:
- Information that is stored in documents
- Information that is stored in systems
- Information that is already drawn out by the client end stakeholders
b) Requirements Elicitation – Elicitation is an added but extremely significant step to fetch the information from stakeholders, which is not readily available on documents. It can be carried out via. processes like Interviewing, where RE team puts questions to stakeholders about the system that they use and the system that they want to be developed.
This basically revolves around answering 6 significant questions:-
- Who should be involved?
- What do they want?
- Where (in what context) could it work?
- Why do they want it?
- How will we know?
- When should we build it?
In this step, it is also necessary to understand the organizational culture of customers and be aware of what tools, models and practices have worked for them. The same tools, models and practices that provided results in collocated teams might not work well in case of distributed teams.
2) Analysis
This principle states to convert gathered raw data into contract style documented lists of requirements and eventually visualize the system before even it has been constructed. There are three key tools to cover Analysis viz.:
a) Requirements Listing – This step involves creating checklist of requirements and further establishing an agreement on that list between project sponsor and developers.
In case of larger systems, this can be a high level description, from which lower level requirements can be derived.
b) Prototypes – This involves creating a dummy version, which allows sponsors and developers to get an idea how the system will look like. Prototypes, in past, have led to early detection of future changes, leading to overall cost reduction.
This also results in major improvements in communication between sponsors and developers.
c) Scenarios and Use Cases – Use Cases and Scenarios describe the behavior of software and systems in textual format. It also defines how users are intended to work with the software. It generally avoids technical terms or implementation details and remains restricted to language or behavior of the end user or software analyst.
3) Feasibility
This principle states to validate if the requirements fulfill the organizational objectives. It also checks whether the current system will be transformed into the intended or targeted system if the gathered requirements are implemented. There are two key tools to cover Feasibility viz.:
a) Requirements Validation – This step involves verifying whether the defined requirements meet customer needs. Finding and rectifying a bug in requirements, after delivery, may cost up to 100 times more than the price of fixing it during the nascent stages.
It involves answering 4 key questions: –
- Consistency: Are there any conflicting requirements?
- Completeness: Have all major function points mentioned by the customer been pondered over and included?
- Realism: Is it really possible to implement the requirements in the given budget, timeframe and technology?
- Verifiability: Can the requirements be checked?
b) Requirement Reviews – This step involves reviewing the requirements at regular intervals by developers along with client and contractor staff.
This involves answering 4 key questions:-
- Verifiability: Is it really possible to test the requirements in the real world scenarios?
- Comprehensibility: Is it easy to properly understand/comprehend the requirement?
- Traceability: Do we clearly know and have mentioned the root/origin of a requirement?
- Adaptability: Is the requirement modifiable, without much impact on its peer requirements?
DOCUMENTING THE SAGA – REQUIREMENTS MANAGEMENT
Requirements Management is the process of documenting the requirements collected during the RE process or during development. This involves creating a detailed description of the information gathered during the three steps of VAF.
“So it was documented that you need a Globe”- the Analyst said
“Yes correct, but I need the Globe to be a square” – the Client introduced a change
Changes in requirements due to evolving business needs of client are inevitable and most certain to happen. Different viewpoints would create different requirements and hence lead to another significant aspect of RE – Change Management.
CHANGE MANAGEMENT
It involves three steps viz.:
a) Problem analysis – Iterative step to identify the exact problem in the existing requirements and propose a change
b) Change analysis – Effect of incorporating the change, on the overall budget and other related requirements
c) Change implementation – Step to update the requirements document and inform the concerned teams.
“I learnt the art of RE and developed the Blue Square Globe with Brown 1 mm thin perimetric lines, as documented”- The smart developer said “Perfect! This is what I wanted but can you add just one more thing” – Happy customer rejoiced “Sure we can take that offline 🙂 ”- The RE Expert development team said
If you are still not convinced with RE, check out our video
