How to become a real analyst? Part 2. Identify requirements

    Good time of day, dear Habravites! This article is a continuation of the topic , and in it I would like to start a discussion of the stage of creating requirements. If you successfully cope with this stage of the process, you will get a great product, happy customers and satisfied developers. Otherwise, you will face misunderstanding, disappointment, and disagreement.

    The stage of creating or developing requirements can conditionally be divided into 4 stages.
    1. Identification of requirements (collection of information).
    2. Requirements analysis.
    3. Specification (documentation) of requirements.
    4. Verification of requirements.

    Do not expect that all actions to identify, analyze, specification and verify requirements, you can perform consistently.
    Working with users, you will ask questions, listen to answers and observe their actions (identification of requirements). Then you process the information received, classify it into various categories and correlate the needs of customers with possible software requirements (analysis). Then you fill out the information from clients and the developed requirements in the form of written documents and diagrams (specification), invite user representatives to confirm that the text you wrote is accurate and complete, and ask them to correct possible errors (verification). Stages will be performed alternating and periodically repeating. This iterative process is the procedure for creating requirements.

    Identification of requirements is the most difficult, important, error-prone and requires intensive communication stage of software development.
    Identification of requirements is a creative process, and each uses its own tools to obtain a result, i.e. requirements. In my luggage there are such methods that I call "Classic", i.e. these are the tricks that work in 90% of cases. The traditional methods for identifying requirements include the use of interviews and questionnaires, observation and study of business documents. These are simple and economical methods. I hope experienced habrausers complement their list.

    Dividing users into groups

    In order not to lose sight of the needs of individual users, it is necessary:
    1. Try to classify users according to various characteristics. For example, by the frequency of work with the software, the functions used, the level of privileges and skills.
    2. Select an active user in each user class. This person will represent the interests of a certain class of users, and make decisions on their behalf.

    IMHO: Choose not those people who talk a lot, but those who speak in essence.

    Work with users to find out product requirements

    1. Questioning / Interviewing

    Find out from users what tasks they need to perform using software. Discuss how the client should interact with the system to complete each such task. Use the following questions in your conversation: What prevents the user from successfully completing a task? How should the system respond to various erroneous conditions? What will happen when? Have you ever needed ?, Where do you get ?, Why are you doing (or not doing)? and anyone ever?
    Correctly formulated questions make the interlocutor think, help focus on the final result, fill in an awkward silence, suggest a new turn of the conversation and help establish contact with the interlocutor.
    The ability to ask questions is a useful technology, the development of which can provide invaluable support in the work. On the Internet, a lot of material on this topic, do not be too lazy to study it!
    After each interview, document the information discussed and ask participants to review the list and make corrections. Viewing in the early stages is necessary for the successful collection of requirements, since only those people who have submitted these requirements can judge whether they are correctly recorded.

    2. Observation

    Observe the user's work. Do not be too lazy to spend a working day on it! Using this method, you can identify implicit system requirements that the user has not voiced. Sometimes it even turns out that to complete the tasks users do not need new software at all.

    3. Holding joint seminars

    Joint requirements workshops, where the analyst and users work closely together, are a great way to identify user needs and draft document requirements.
    The main thing:
    1. You must lead the seminar in such a way as to get the desired result.
    2. Consider in advance how to organize the interaction most effectively.
    3. It is necessary to involve all participants in the seminar.

    It is important not to forget to document the source of each requirement in order to subsequently understand the needs of which user the system will satisfy.

    Examination of reports on problems of working systems or a similar system in order to search for new ideas

    To identify requirements, you can use information from the support service. Examine customer reports of problems and suggestions for enhanced functionality. You can also study similar systems (competitor systems), identify their strengths and weaknesses. These are great sources for finding ideas that can be implemented in future versions or in a new product.

    Reuse requirements across projects

    If the functionality required by the customer is already implemented in another product, offer the customer the flexibility to revise their requirements to use existing components.

    How to understand that the collection of requirements is completed?

    There are no specific signs indicating that the identification of requirements has been completed. It is completely impossible to identify the requirements, however, the following signs will tell you that the sources of information are almost exhausted:
    1. users can no longer come up with new use cases.
    2. Users offer new use cases, but you have already deduced the corresponding functional requirements from other use cases.
    3. Users describe issues that have already been discussed.
    4. proposed new features are beyond the scope of the project;
    5. users offer features that it makes sense to realize sometime later.

    Despite all your efforts, you cannot identify all the requirements, so be prepared to make changes as you work on the project. Remember: your goal is to formulate requirements sufficient to ensure that an acceptable level of risk is developed during development.
    In the next article I will share with you the experience of analyzing requirements, consider various graphical models and more. Until next time.


    Karl Wigers “Software Requirements Development”

    Also popular now: