⬆️ ⬇️

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.



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.



image



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