How to become a real analyst? Part 2. Identify the requirements
Good time of day, dear habravchane! This article is a continuation of the topic , and I would like to begin a discussion on 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 face misunderstanding, frustration and disagreement.
The stage of creating or developing requirements can be divided into 4 stages.
Do not expect that all actions to identify, analyze, specify and verify requirements, you can perform consistently.
Working with users, you will ask questions, listen to the answers and watch their actions (identification of requirements). Then you process the information received, classify it into various categories, and relate customer needs to possible software requirements (analysis). Then you fill in the information from clients and the developed requirements in the form of written documents and diagrams (specification), ask the user representatives to confirm that the text you have written is accurate and complete, and ask them to correct any errors (verification). Stages will be performed, alternating and periodically repeating. This iterative process is a requirement creation procedure.
Identifying requirements is the most difficult, important, error-prone and software development phase that requires intensive communication.
Identifying requirements is a creative process, and each uses its own tools to get a result, i.e. requirements. There are such methods in my luggage that I call “Classic”, i.e. These are the techniques that work in 90% of cases. Traditional methods of identifying requirements include using interviews and questionnaires, observing and studying business documents. These are simple and cost effective methods. I hope, experienced habrayuzery add to the list of their own.
')
Not to lose sight of the needs of individual users:
IMHO: Choose not those people who talk a lot, but those who speak essentially.
Find out from users what tasks they need to perform software. Discuss how the client should interact with the system for 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 error conditions? What happens when? Have you ever been required? Where do you get? Why do you do (or do not)? and anybody ever?
Correctly formulated questions make the interlocutor think, help focus on the final result, fill an awkward silence, suggest a new twist to the conversation and help to 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 lazy to study it!
After each interview, document the information that was discussed, and ask participants to look through the list and make corrections. Early viewing is necessary for successful claims collection, since only those people who have submitted these requirements can judge whether they are properly recorded.
Watch the user experience. Do not be lazy to spend this work day! Using this method, you can identify implicit system requirements that the user has not voiced. Sometimes it even turns out that users do not need new software at all to perform tasks.
Collaborative requirements identification workshops, where the analyst and users work closely together - a great way to identify user needs and draft requirements documents.
The main thing:
It is important to remember to document the source of each requirement in order to subsequently understand the needs of which user the system will satisfy.
To identify requirements, you can use information from the support service. Examine customer problem reports and feature extensions. It is also possible to study similar systems (systems of competitors), to identify their strengths and weaknesses. These are excellent sources for finding ideas that can be implemented in future versions or in a new product.
If the functionality required by the client is already implemented in another product, offer the client to flexibly reconsider their requirements for the use of existing components.
There are no specific signs showing 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 have almost dried up:
Despite all your efforts, you will not be able to 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 an acceptable level of risk during development.
In the next article I will share with you the experience of analyzing requirements, we will consider various graphical models and not only. Until next time.
Karl Wigs "Developing Software Requirements"
The stage of creating or developing requirements can be divided into 4 stages.
- Identification of requirements (collection of information).
- Requirements analysis.
- Specification (documentation) requirements.
- Checking requirements.
Do not expect that all actions to identify, analyze, specify and verify requirements, you can perform consistently.
Working with users, you will ask questions, listen to the answers and watch their actions (identification of requirements). Then you process the information received, classify it into various categories, and relate customer needs to possible software requirements (analysis). Then you fill in the information from clients and the developed requirements in the form of written documents and diagrams (specification), ask the user representatives to confirm that the text you have written is accurate and complete, and ask them to correct any errors (verification). Stages will be performed, alternating and periodically repeating. This iterative process is a requirement creation procedure.
Identifying requirements is the most difficult, important, error-prone and software development phase that requires intensive communication.
Identifying requirements is a creative process, and each uses its own tools to get a result, i.e. requirements. There are such methods in my luggage that I call “Classic”, i.e. These are the techniques that work in 90% of cases. Traditional methods of identifying requirements include using interviews and questionnaires, observing and studying business documents. These are simple and cost effective methods. I hope, experienced habrayuzery add to the list of their own.
')
Separation of users into groups
Not to lose sight of the needs of individual users:
- Try to classify users according to different characteristics. For example, in terms of frequency with software, functions used, privilege level and skills.
- Select the 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 essentially.
Work with users to find out product requirements
1. Questioning / Interviewing
Find out from users what tasks they need to perform software. Discuss how the client should interact with the system for 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 error conditions? What happens when? Have you ever been required? Where do you get? Why do you do (or do not)? and anybody ever?
Correctly formulated questions make the interlocutor think, help focus on the final result, fill an awkward silence, suggest a new twist to the conversation and help to 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 lazy to study it!
After each interview, document the information that was discussed, and ask participants to look through the list and make corrections. Early viewing is necessary for successful claims collection, since only those people who have submitted these requirements can judge whether they are properly recorded.
2. Observation
Watch the user experience. Do not be lazy to spend this work day! Using this method, you can identify implicit system requirements that the user has not voiced. Sometimes it even turns out that users do not need new software at all to perform tasks.
3. Conducting joint workshops
Collaborative requirements identification workshops, where the analyst and users work closely together - a great way to identify user needs and draft requirements documents.
The main thing:
- You must conduct the seminar in such a way as to obtain the desired result.
- Think in advance how to organize the interaction most effectively.
- It is necessary to involve all participants in the process.
It is important to remember 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 find new ideas
To identify requirements, you can use information from the support service. Examine customer problem reports and feature extensions. It is also possible to study similar systems (systems of competitors), to identify their strengths and weaknesses. These are excellent sources for finding ideas that can be implemented in future versions or in a new product.
Reuse requirements in different projects
If the functionality required by the client is already implemented in another product, offer the client to flexibly reconsider their requirements for the use of existing components.
How to understand that requirements collection is complete?
There are no specific signs showing 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 have almost dried up:
- users can no longer come up with new uses.
- Users offer new use cases, but you have already deduced the relevant functional requirements from other use cases.
- users describe problems that have already been discussed;
- proposed new features are beyond the scope of the project;
- users offer features that it makes sense to realize sometime later.
Despite all your efforts, you will not be able to 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 an acceptable level of risk during development.
In the next article I will share with you the experience of analyzing requirements, we will consider various graphical models and not only. Until next time.
Literature:
Karl Wigs "Developing Software Requirements"
Source: https://habr.com/ru/post/178379/
All Articles