Software Requirements: Collection and Documentation Guidelines
Today we want to bring to your attention the book by Ilya Kornipayev “ Requirements for software: Guidelines for collecting and documenting ”, which is being prepared for release in our publishing house.
This book is about how to collect, document, and verify requirements. It is designed for a wide range of readers: novice analysts, designers, architects, developers, testers, project managers, and other professionals involved in software development projects in the early stages.
The reader, regardless of whether he works on the developer’s side of the company, is or he is representative of the customer, or works in the IT department of a company not related to software development, can find useful tips and recommendations in the book.
The book is written on the basis of more than fifteen years of experience of the author, as well as on the materials of the author's courses on the development and management of requirements.
')
Another concept is very uncommon in the development of requirements - these are Key Performance Criteria (or Indicators). This term is known to all. In the original, these are all well-known KPIs - Key Performance Indicators. But the meaning of this term in terms of its application in the development of requirements needs to be clarified.
By analogy with the Key Requirements, the Key Performance Criteria determine the values of the system performance parameters, without which the system will not be useful to the customer, and, therefore, cannot be accepted for commercial operation.
It is worth explaining at once why I paid attention to this issue. I have repeatedly seen situations when the performance criterion was written in the form:
21.1. The system must store information entered on any form in no more than 2 seconds.
or
21.2. The system should return search results in no more than 5 seconds.
In principle, normal performance criteria. However, what can happen if, at the end of the project, it turns out that the system does not satisfy one of them? First, why at the end? Secondly, what happens?
In the end, because performance parameters are usually checked when a list of functional requirements is developed and verified. And the following happens: deficiencies in system performance usually lie at a fairly low level, as the developers say - “in the core”. And quite low-level code changes begin, which often lead to problems with working and already tested functionality of the system. If we express ourselves on the developers' slang, “we started tyuning peformats and this led to a crust refactoring, which is why the functional went.” Those. tried to achieve compliance with the performance parameters, and eventually broke the system, and this, I recall, at the end of the project. As a result, the team gets into time trouble, everyone starts to work overtime, attention is lost, and, in the end, the team can go to the date of delivery of the project with a non-working system.
How can an analyst help his team in a situation when the system does not meet the performance criteria in the later stages? First, the analyst should try to determine with the interested parties which performance criteria are really key, and without achieving them, the system cannot be put into commercial operation. Secondly, at the stage of requirements gathering, the analyst should understand the function of each performance criterion, this is especially important for the key ones.
Figure 8 shows the four functions of performance metrics. Often, analysts are limited to the first function, i.e. fix a certain amount. In fact, this is quite a rare case.
Let us consider an example on the chart a) The customer needs the system to support 100 simultaneously working users. This means that it has 100 real users and cannot be less, and more is not expected in the foreseeable future.
Graphs b) and c) reflect more common cases. For most web solutions, the load is probabilistic in nature, which means that the requirement that the system must support 200 users simultaneously working with the system is also likely to be forecast. Moreover, for new sites, the number of simultaneously working users at the beginning of their work in the industrial operation mode can be much less. Therefore, if a team encounters problems while meeting this performance criterion, it may be worthwhile not to try to solve these problems for the remaining few days before the end of the project, but agree with the customer on accepting a system with a lower value of this indicator, provided that the team then finalizes system and deliver it to the customer again later. Especially it makes sense when several deliveries are planned (project phases), respectively, and the system performance can be increased gradually. As can be seen in the graph b), customer satisfaction when reaching the value of 100 users simultaneously working with the system will be approximately 70%. I believe that in such a situation the customer is likely to meet the development team and would prefer to get a working system in time, with a lower value of the performance criterion, than to agree to postpone the implementation.
Fig.8. Functions of the performance indicator value.
Graph c) shows a similar situation with the only difference that in this case the customer is interested in minimizing the value of the performance criterion. For example, the time the system executes a search query should not exceed 3 seconds. At the same time, it follows from the schedule that the achievement of the system by the value of this indicator equal to 5 s gives about 90% customer satisfaction, and even 7 s gives about 70%, therefore, as the graph shows, everything that is better than 7 s, but less than 3 s, can be accepted by the customer, after additional negotiations and, most likely, subject to free development of the system in the future. The team can deliver the project on time, and then in the next delivery improve the system in accordance with the initial requirements.
In some cases, customer satisfaction with the value of a performance indicator can be described by function e). This is quite a rare case when a certain value is required, but deviations from it within acceptable limits are still acceptable, although customer satisfaction with these deviations is reduced.
The analyst’s understanding of the function of the value of the performance indicator, especially if it is key, can help the development team at the later stages of the project, so it’s worth paying enough attention to this issue when gathering requirements.
Foreword
Main questions: Why? For whom? What?
How to read this book. The structure of the book. Disclaimer
Introduction
What are the requirements?
Communication when developing systems
Problem area and solution area
Number of requirements and decision choice
Problems associated with a premature transition to solutions
Customer expectations management
Types of requirements
Requirements and quality
Requirements and modeling
Requirements and changes
The source of change is the customer
Market as a source of change
Developers as a source of change
Other characteristic difficulties
High uncertainty
Different cultural and educational level of project participants
Contradictions
Natural language use
The scope and depth of the requirements
Overview of requirements development
Chapter 1. Identifying stakeholders and their representatives.
Stakeholders in the project
Identifying stakeholder representatives to collect requirements
Interaction diagram
Selection of a representative of the interested party
Stakeholders and their goals
Stakeholders and their problems
Conclusion
Chapter 2. Collecting Requirements
Overview of Requirements Sources
Requirements collection planning
People as a source for gathering requirements
Preparing for the meeting
Interview
How does the meeting begin?
How to sit?
To set up a contact
Introduction
Questions and answers
End of meeting
After meeting
Telephone calls
Correspondence
Group meetings
Requirements Workshop
Polls
Other ways of obtaining requirements
Observation of the work of people
Temporary performance by the analyst of current work of future users of the system
Experts and Consultants
Systems
Documents
Contact support
Prototypes
Dangerous prototypes
Conclusion
Chapter 3. Working with Collected Requirements
Where does a good document begin
Requirements structure
Requirement text
Requirements Attributes
Key requirements
Key Performance Criteria
Conclusion
Chapter 4. Requirements Verification
The importance of checks
Types of checks
Informal peer reviews (Peer Review)
Requirements text verification criteria
Criteria for a complete set of requirements
More about checks
Conclusion
Literature
annotation
This book is about how to collect, document, and verify requirements. It is designed for a wide range of readers: novice analysts, designers, architects, developers, testers, project managers, and other professionals involved in software development projects in the early stages.
The reader, regardless of whether he works on the developer’s side of the company, is or he is representative of the customer, or works in the IT department of a company not related to software development, can find useful tips and recommendations in the book.
The book is written on the basis of more than fifteen years of experience of the author, as well as on the materials of the author's courses on the development and management of requirements.
')
Fragment from Chapter 3.
Key Performance Criteria
Another concept is very uncommon in the development of requirements - these are Key Performance Criteria (or Indicators). This term is known to all. In the original, these are all well-known KPIs - Key Performance Indicators. But the meaning of this term in terms of its application in the development of requirements needs to be clarified.
By analogy with the Key Requirements, the Key Performance Criteria determine the values of the system performance parameters, without which the system will not be useful to the customer, and, therefore, cannot be accepted for commercial operation.
It is worth explaining at once why I paid attention to this issue. I have repeatedly seen situations when the performance criterion was written in the form:
21.1. The system must store information entered on any form in no more than 2 seconds.
or
21.2. The system should return search results in no more than 5 seconds.
In principle, normal performance criteria. However, what can happen if, at the end of the project, it turns out that the system does not satisfy one of them? First, why at the end? Secondly, what happens?
In the end, because performance parameters are usually checked when a list of functional requirements is developed and verified. And the following happens: deficiencies in system performance usually lie at a fairly low level, as the developers say - “in the core”. And quite low-level code changes begin, which often lead to problems with working and already tested functionality of the system. If we express ourselves on the developers' slang, “we started tyuning peformats and this led to a crust refactoring, which is why the functional went.” Those. tried to achieve compliance with the performance parameters, and eventually broke the system, and this, I recall, at the end of the project. As a result, the team gets into time trouble, everyone starts to work overtime, attention is lost, and, in the end, the team can go to the date of delivery of the project with a non-working system.
How can an analyst help his team in a situation when the system does not meet the performance criteria in the later stages? First, the analyst should try to determine with the interested parties which performance criteria are really key, and without achieving them, the system cannot be put into commercial operation. Secondly, at the stage of requirements gathering, the analyst should understand the function of each performance criterion, this is especially important for the key ones.
Figure 8 shows the four functions of performance metrics. Often, analysts are limited to the first function, i.e. fix a certain amount. In fact, this is quite a rare case.
Let us consider an example on the chart a) The customer needs the system to support 100 simultaneously working users. This means that it has 100 real users and cannot be less, and more is not expected in the foreseeable future.
Graphs b) and c) reflect more common cases. For most web solutions, the load is probabilistic in nature, which means that the requirement that the system must support 200 users simultaneously working with the system is also likely to be forecast. Moreover, for new sites, the number of simultaneously working users at the beginning of their work in the industrial operation mode can be much less. Therefore, if a team encounters problems while meeting this performance criterion, it may be worthwhile not to try to solve these problems for the remaining few days before the end of the project, but agree with the customer on accepting a system with a lower value of this indicator, provided that the team then finalizes system and deliver it to the customer again later. Especially it makes sense when several deliveries are planned (project phases), respectively, and the system performance can be increased gradually. As can be seen in the graph b), customer satisfaction when reaching the value of 100 users simultaneously working with the system will be approximately 70%. I believe that in such a situation the customer is likely to meet the development team and would prefer to get a working system in time, with a lower value of the performance criterion, than to agree to postpone the implementation.
Fig.8. Functions of the performance indicator value.
Graph c) shows a similar situation with the only difference that in this case the customer is interested in minimizing the value of the performance criterion. For example, the time the system executes a search query should not exceed 3 seconds. At the same time, it follows from the schedule that the achievement of the system by the value of this indicator equal to 5 s gives about 90% customer satisfaction, and even 7 s gives about 70%, therefore, as the graph shows, everything that is better than 7 s, but less than 3 s, can be accepted by the customer, after additional negotiations and, most likely, subject to free development of the system in the future. The team can deliver the project on time, and then in the next delivery improve the system in accordance with the initial requirements.
In some cases, customer satisfaction with the value of a performance indicator can be described by function e). This is quite a rare case when a certain value is required, but deviations from it within acceptable limits are still acceptable, although customer satisfaction with these deviations is reduced.
The analyst’s understanding of the function of the value of the performance indicator, especially if it is key, can help the development team at the later stages of the project, so it’s worth paying enough attention to this issue when gathering requirements.
TABLE OF CONTENTS
Foreword
Main questions: Why? For whom? What?
How to read this book. The structure of the book. Disclaimer
Introduction
What are the requirements?
Communication when developing systems
Problem area and solution area
Number of requirements and decision choice
Problems associated with a premature transition to solutions
Customer expectations management
Types of requirements
Requirements and quality
Requirements and modeling
Requirements and changes
The source of change is the customer
Market as a source of change
Developers as a source of change
Other characteristic difficulties
High uncertainty
Different cultural and educational level of project participants
Contradictions
Natural language use
The scope and depth of the requirements
Overview of requirements development
Chapter 1. Identifying stakeholders and their representatives.
Stakeholders in the project
Identifying stakeholder representatives to collect requirements
Interaction diagram
Selection of a representative of the interested party
Stakeholders and their goals
Stakeholders and their problems
Conclusion
Chapter 2. Collecting Requirements
Overview of Requirements Sources
Requirements collection planning
People as a source for gathering requirements
Preparing for the meeting
Interview
How does the meeting begin?
How to sit?
To set up a contact
Introduction
Questions and answers
End of meeting
After meeting
Telephone calls
Correspondence
Group meetings
Requirements Workshop
Polls
Other ways of obtaining requirements
Observation of the work of people
Temporary performance by the analyst of current work of future users of the system
Experts and Consultants
Systems
Documents
Contact support
Prototypes
Dangerous prototypes
Conclusion
Chapter 3. Working with Collected Requirements
Where does a good document begin
Requirements structure
Requirement text
Requirements Attributes
Key requirements
Key Performance Criteria
Conclusion
Chapter 4. Requirements Verification
The importance of checks
Types of checks
Informal peer reviews (Peer Review)
Requirements text verification criteria
Criteria for a complete set of requirements
More about checks
Conclusion
Literature
Source: https://habr.com/ru/post/171545/
All Articles