March 4, 2013 at 15:27Software Requirements: Guidelines for Collecting and Documenting
Today we want to bring to your attention a book by Ilya Kornipaeva " Requirements for software: Recommendations regarding the collection and documentation ", which is preparing to enter 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 specialists involved in early software development projects.
The reader, regardless of whether he works on the side of the developer company, is either he is the customer’s representative, or works in the IT department of the 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 copyright courses on the development and management of requirements.
Another concept is very little common in the field of requirements development - these are Key Performance Criteria (or Indicators). This term is known to all. In the original, these are the well-known KPIs - Key Performance Indicators. But the meaning of this term in terms of its application in the field of requirements development needs to be clarified.
By analogy with the Key Requirements, Key Performance Criteria determine the values of system performance parameters, without which the system will not be useful to the customer, and, therefore, cannot be taken into commercial operation.
It is worth immediately explaining why I paid attention to this issue. I have repeatedly seen situations where the performance criterion was written as:
21.1. The system must save 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 suddenly at the end of the project it is discovered that the system does not satisfy one of them? First, why at the end? Secondly, what is happening?
In the end, because performance parameters are usually checked when a list of functional requirements is developed and verified. And the following happens: flaws in system performance usually lie at a fairly low level, as the developers say - "in the kernel." And quite low-level code changes begin, which often lead to problems with the working and already tested functionality of the system. To put it in the slang of the developers - “we began to tuned peformas and this led to refactoring, which caused the functional to go”. Those. they tried to achieve compliance with the performance parameters, but eventually broke the system, and this, I recall, at the end of the project. As a result, the team gets into time pressure, everyone starts working overtime, attention is lost, and, in the end,
How can an analyst help his team in a situation where the system in the later stages does not meet the performance criteria? First, the analyst should try to determine, together with interested parties, which performance criteria are really key, and without achieving them, the system cannot be put into commercial operation. Secondly, the analyst at the stage of collecting requirements must understand the function of each performance criterion, this is especially important for key ones.
Figure 8 shows four performance metrics features. Often, analysts are limited to the first function, i.e. fix a certain amount. In fact, this is a rather rare case.
Let us examine an example on the graph a) The customer needs the system to support 100 simultaneously working users. This means that it has 100 real users and it 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, which means that the requirement that the system should support 200 users working simultaneously with the system is also likely to be forecast. Moreover, for new sites, the number of concurrent users at the beginning of work in the mode of commercial operation can be significantly less. Therefore, if a team encounters problems in meeting this performance criterion, it might be worthwhile not to try to solve these problems for the remaining few days before the end of the project, but rather agree with the customer to accept a system with a lower value of this indicator, provided that the team then completes system and deliver it to the customer again later. Especially it makes sense when several deliveries (project phases) are planned, accordingly, system performance can increase gradually. As can be seen in chart b), customer satisfaction when reaching 100 at the same time users of the system will be approximately 70%. I believe that in this situation, the customer is likely to meet the development team and prefer to get a working system with a lower performance criterion in time than agree to postpone the implementation deadlines.
Fig. 8. Functions of a value of a productivity indicator.
Graph c) shows a similar situation with the only difference being that in this case, the customer is interested in minimizing the value of the performance criterion. For example, the time it takes for the system to complete a search query should not exceed 3 s. While it follows from the graph that achieving a value of 5 s by the system gives about 90% of customer satisfaction, and even 7 s gives about 70%, therefore, as the graph shows, everything that is better than 7 s, but falls short of 3 s, can be accepted by the customer, after additional negotiations and, for sure, subject to free system development in the future. The team can deliver the project on time, and then in the next delivery to improve the system in accordance with the initial requirements.
In some cases, customer satisfaction with a performance indicator can be described by function e). This is a rather rare case when a certain quantity is required, but deviations from it within acceptable limits are still acceptable, although the degree of customer satisfaction with these deviations decreases.
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 later stages of the project, so you should pay enough attention to this issue when collecting requirements.
Foreword
Key questions: Why? For whom? What?
How to read this book. The structure of the book. Disclaimer
Introduction
What are requirements?
Communication during the development of systems
Problem area and solution area
Number of requirements and choice of solution
Problems associated with premature transition to the solution area
Managing customer expectations
Types of requirements
Requirements and quality
Requirements and modeling
Requirements and changes
Source of changes - customer
Market as a source of changes
Developers as a source of changes
Others characteristic difficulties
High uncertainty
Different cultural and educational levels of the project participants.
Contradictions.
Use of the natural language.
Volume and depth of requirements
development. Overview of requirements development process.
Chapter 1. Identification of stakeholders and their representatives.
Stakeholders in the project.
Identification of stakeholders to gather requirements.
Interaction diagram.
Selecting a representative of the interested party.
Interested parties and their goal
Stakeholders and their issues
Conclusion
Chapter 2. Collection is required REPRESENTATIONS
overview of sources of requirements
gathering requirements Planning for
People as the source for requirements gathering
Preparing for the meeting
Interview
How does the meeting begin?
How to sit down?
Establish a contact
Introduction
Questions and answers
End of a meeting
After a meeting
Telephone conversations
Correspondence
Group meetings
Work group workshop (Requirements Workshop)
Surveys
Other ways to get requirements
Observing people’s work
Temporal performance by an analyst of the current work of future users of the system
Experts and consultants
Systems
Documents
Appeals to the support service
Prototypes
Dangerous prototypes
Conclusion
Chapter 3. Working with collected requirements
What a good document starts
with Requirements structure Requirements
text Requirements
attributes
Key requirements
Key performance criteria
Conclusion
Chapter 4. Requirements
verification The importance of verifications
Types of verifications
Informal peer reviews (Peer Review)
Criteria for verifying requirements text
Criteria for a complete set of requirements
A little 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 specialists involved in early software development projects.
The reader, regardless of whether he works on the side of the developer company, is either he is the customer’s representative, or works in the IT department of the 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 copyright courses on the development and management of requirements.
Fragment from Chapter 3.
Key Performance Criteria
Another concept is very little common in the field of requirements development - these are Key Performance Criteria (or Indicators). This term is known to all. In the original, these are the well-known KPIs - Key Performance Indicators. But the meaning of this term in terms of its application in the field of requirements development needs to be clarified.
By analogy with the Key Requirements, Key Performance Criteria determine the values of system performance parameters, without which the system will not be useful to the customer, and, therefore, cannot be taken into commercial operation.
It is worth immediately explaining why I paid attention to this issue. I have repeatedly seen situations where the performance criterion was written as:
21.1. The system must save 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 suddenly at the end of the project it is discovered that the system does not satisfy one of them? First, why at the end? Secondly, what is happening?
In the end, because performance parameters are usually checked when a list of functional requirements is developed and verified. And the following happens: flaws in system performance usually lie at a fairly low level, as the developers say - "in the kernel." And quite low-level code changes begin, which often lead to problems with the working and already tested functionality of the system. To put it in the slang of the developers - “we began to tuned peformas and this led to refactoring, which caused the functional to go”. Those. they tried to achieve compliance with the performance parameters, but eventually broke the system, and this, I recall, at the end of the project. As a result, the team gets into time pressure, everyone starts working overtime, attention is lost, and, in the end,
How can an analyst help his team in a situation where the system in the later stages does not meet the performance criteria? First, the analyst should try to determine, together with interested parties, which performance criteria are really key, and without achieving them, the system cannot be put into commercial operation. Secondly, the analyst at the stage of collecting requirements must understand the function of each performance criterion, this is especially important for key ones.
Figure 8 shows four performance metrics features. Often, analysts are limited to the first function, i.e. fix a certain amount. In fact, this is a rather rare case.
Let us examine an example on the graph a) The customer needs the system to support 100 simultaneously working users. This means that it has 100 real users and it 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, which means that the requirement that the system should support 200 users working simultaneously with the system is also likely to be forecast. Moreover, for new sites, the number of concurrent users at the beginning of work in the mode of commercial operation can be significantly less. Therefore, if a team encounters problems in meeting this performance criterion, it might be worthwhile not to try to solve these problems for the remaining few days before the end of the project, but rather agree with the customer to accept a system with a lower value of this indicator, provided that the team then completes system and deliver it to the customer again later. Especially it makes sense when several deliveries (project phases) are planned, accordingly, system performance can increase gradually. As can be seen in chart b), customer satisfaction when reaching 100 at the same time users of the system will be approximately 70%. I believe that in this situation, the customer is likely to meet the development team and prefer to get a working system with a lower performance criterion in time than agree to postpone the implementation deadlines.
Fig. 8. Functions of a value of a productivity indicator.
Graph c) shows a similar situation with the only difference being that in this case, the customer is interested in minimizing the value of the performance criterion. For example, the time it takes for the system to complete a search query should not exceed 3 s. While it follows from the graph that achieving a value of 5 s by the system gives about 90% of customer satisfaction, and even 7 s gives about 70%, therefore, as the graph shows, everything that is better than 7 s, but falls short of 3 s, can be accepted by the customer, after additional negotiations and, for sure, subject to free system development in the future. The team can deliver the project on time, and then in the next delivery to improve the system in accordance with the initial requirements.
In some cases, customer satisfaction with a performance indicator can be described by function e). This is a rather rare case when a certain quantity is required, but deviations from it within acceptable limits are still acceptable, although the degree of customer satisfaction with these deviations decreases.
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 later stages of the project, so you should pay enough attention to this issue when collecting requirements.
TABLE OF CONTENTS
Foreword
Key questions: Why? For whom? What?
How to read this book. The structure of the book. Disclaimer
Introduction
What are requirements?
Communication during the development of systems
Problem area and solution area
Number of requirements and choice of solution
Problems associated with premature transition to the solution area
Managing customer expectations
Types of requirements
Requirements and quality
Requirements and modeling
Requirements and changes
Source of changes - customer
Market as a source of changes
Developers as a source of changes
Others characteristic difficulties
High uncertainty
Different cultural and educational levels of the project participants.
Contradictions.
Use of the natural language.
Volume and depth of requirements
development. Overview of requirements development process.
Chapter 1. Identification of stakeholders and their representatives.
Stakeholders in the project.
Identification of stakeholders to gather requirements.
Interaction diagram.
Selecting a representative of the interested party.
Interested parties and their goal
Stakeholders and their issues
Conclusion
Chapter 2. Collection is required REPRESENTATIONS
overview of sources of requirements
gathering requirements Planning for
People as the source for requirements gathering
Preparing for the meeting
Interview
How does the meeting begin?
How to sit down?
Establish a contact
Introduction
Questions and answers
End of a meeting
After a meeting
Telephone conversations
Correspondence
Group meetings
Work group workshop (Requirements Workshop)
Surveys
Other ways to get requirements
Observing people’s work
Temporal performance by an analyst of the current work of future users of the system
Experts and consultants
Systems
Documents
Appeals to the support service
Prototypes
Dangerous prototypes
Conclusion
Chapter 3. Working with collected requirements
What a good document starts
with Requirements structure Requirements
text Requirements
attributes
Key requirements
Key performance criteria
Conclusion
Chapter 4. Requirements
verification The importance of verifications
Types of verifications
Informal peer reviews (Peer Review)
Criteria for verifying requirements text
Criteria for a complete set of requirements
A little more about checks
Conclusion
Literature