The practice of forming requirements in IT projects from A to Z. Part 2. Goals and Needs


    IV DEFINING GOALS, PROJECT

    The goal does not have to be achieved. Sometimes it’s just a direction to move on.
    Bruce Lee.


    One of the main features of the system that distinguishes it from disparate components is the subordination of the entire organization of the system to a certain goal. The project work of the team is also a certain system and, accordingly, should “follow the lead” for some purpose. Therefore, having established communication between the project participants, we will begin to determine the goals that we want to achieve as a result of creating a new product.

    The purpose of this group of works: to determine the main tasks that are set for themselves by the groups of stakeholders involved in the project.

    Now, in the literature, a whole bunch of methods for determining and formulating goals is available. There is even such a direction - goal-setting, teaching the rules of setting goals.

    The quote at the beginning of this section, in my opinion, perfectly illustrates the role of goals in a software development project. From my practice, it is extremely rare to return to the goals formulated at the project initiation stage. Formulating goals in this context is rather a declarative step in the proclamation of slogans, raising team spirit and giving the team a start for joint discussion of their near future. In order to prevent a critical assessment of their statements by experts in goal-setting, I’ll immediately make a reservation that in the future we will formulate requirements that detail our goals. These requirements will meet all the principles of SMART technology. SMART - a methodology for assessing the effectiveness of goal-setting according to five criteria (specificity, measurability, reachability, orientation to the result,

    From the point of view of the project manager, correctly formulated goals should allow:

    1. Identify the product that the team must produce during the implementation of the project, and the benefits that the customer should receive as a result of its completion;
    2. Define the criteria for the success of the project as a whole, from the point of view of the main stakeholders, including not only the customer, but also the project team.

    Therefore, the goal of the analyst at this stage is to provide the team and the customer with this information.

    When determining goals, it is important to consider two important points:

    1. The customer is most often unable to independently formulate goals in a quality manner;
    2. The objectives in the project for different representatives of the customer, contractors and contractors are different, and sometimes conflicting.

    Therefore, firstly: you must help representatives of the customer to formulate the goals that they want to achieve as a result of the implementation of the target product. Secondly: when formulating the goals of the customer, you must take into account your own strategic development goals that you want to achieve as a result of the work. For example, this may be an attempt to lay in the functionality of the developed system - characteristics that are not essential for the customer, but are of interest for you to bring to the market the developed target product.

    Once again, I will specifically draw your attention to the fact that when formulating the goals of the project, you should try to lay in them your own (implementation teams) strategic interests that you want to achieve as a result of your activities in the project.

    But when determining the goals of the customer, together with his representatives, the analyst must first of all operate with the concept of the benefits that the owner will receive from using each function of the target system under consideration. Therefore, when the customer asks you to realize some opportunity, teach him to think immediately, and what profit he will get from this. So you can even at the initial stage dismiss some of the excessive requirements and save time at the stage of determining the boundaries of the project, but more on that later.

    Figure 4.1 shows the process of forming the goals of creating an information system.



    Figure 4.1 - model of the process of forming goals

    Having discarded the general goals of the requirements development process, we will try to single out the main tasks that the training system “Requirements Management” we are designing must solve to meet existing customer needs. Since in the training project I also perform the function of an analyst and imitate the activities of the customer, I will give “our joint” thoughts on the formulation of each goal.

    First of all, you should turn to available sources that describe the problems and solutions of the automated subject area. According to SWEBOK (Software Engineering Body of Knowledge), the requirements analysis of the Requirement Process consists of the following main components:

    • Requirements Elicitation,
    • Requirements Analysis
    • Requirements Specification
    • Requirements Validation.

    Therefore, we must embrace this entire workflow. And it is desirable to carry them out, as we found in the previous chapter, adhering to a single style, using a single "environment" for all processes and project participants.

    So, the first process that we will carry out when developing requirements is the collection of information about the tasks, goals and problems of the customer, which he is going to solve with the help of the created (target) product. Based on these wishes, certain customer needs (user requirements) will be formulated that are suitable for further work on their implementation.

    Add the term to the glossary:



    We must fix this information and be sure to provide it for discussion to all interested parties of the project, with the possibility of their addition and change. Where does the first goal of our system come from:

    1. Fix a list of user needs that they want to satisfy with the help of the target product.

    Based on the needs to be automated with the customer (problem domain), we will formulate specifications for the product being developed (solution domain) using well-known techniques, which will be described below. Since most of the software product development process is built around requirements specifications, the following is the goal of our system:

    2. To fix the list of functional and system requirements for the developed product. Add a small clarification: including fixing the coverage of user wishes (problem areas) with system requirements (solution area).

    We agree on the term requirements in the Glossary:



    The requirements specifications will become in our system a framework linking all parts of the project from the customer’s needs (since they are clearly related to the specifications) to the implemented functions in the target product. To do this, based on the specifications, we will put tasks to the performers for design, development, testing, deployment, pilot implementation, etc. Developers in the code indicate a link to the task. For the task, you can find out the requirements, etc. in the reverse direction to the needs of the user. Based on the above postulates, we formulate the following goal:

    3. Based on the specification of requirements, assign tasks to performers aimed at their implementation in the final product.

    Since the fact that the task is completed, in fact, performs the promotion of the product’s functionality to the planned characteristics, we need to fix in the system all the actions taken by the performers on the tasks. Thus, we will be able to track the increment of the functionality of the target product in terms of time and each individual requirement. Therefore, the following goal can be formulated as follows:

    4. Fix the fact of the fulfillment of tasks by performers.

    In almost every project, during its implementation, changes and clarification of requirements occur. This is a separate section in the discipline "Requirements Analysis" and we cannot mention this process in our project, and therefore there is one more goal:

    5. Manage requirements changes.

    Now that we’ve figured out the main goals, we’ll move on to formulating customer needs that will satisfy our goals.

    V REFINING THE CUSTOMER'S NEEDS


    Of all the possible ways to improve the software development process, the greatest advantage is in formulating requirements.
    Karl Wigers



    The discipline "System analysis", to combat complexity, proposes the use of such basic techniques as abstraction and decomposition, allowing to lay out the requirements for presentation levels. Following these principles, the goals of the analysis pyramid are, for example, described in the previous section. Rising up, we decompose them into smaller elements, collecting customer wishes for the functionality of the product being developed.

    The purpose of this group of works: to collect the most complete and accurate information about the needs of the customer, which they want to satisfy with the help of the target product.

    When collecting customer needs, it is necessary to remember: if potential users of the system state any wishes that we cannot associate with any of the goals, we should clarify with the customer the need to automate this need, or revise the goals again.

    Another important caveat: do not try to describe the needs of users in terms of a software product, this is bad practice. Avoid expressions such as: “selection in the menu”, “pressing the button”, “entering into the field”, etc., but use for example: “selecting an option”, “executing a process”, “determining a value”, etc. .



    Figure 5.1 - model of the process of formalizing customer needs

    Further we will expand and detail this model (see Fig. 5.1), moving from section to section in the process of forming requirements specifications.

    1. ACTING USER STORIES TO DETERMINE THE CUSTOMER'S NEEDS


    In my opinion, from the very beginning of the project, it is very convenient to use the method of describing "User stories". This technique is well described in Scrum agile programming techniques, KANBAN [10]. Its essence is that the team, together with the owners of the processes, makes small, in one or two sentences, scenarios of business processes to be automated. For each User Story (English User Story), a goal is determined that must be achieved as a result of its implementation. If the goal is difficult to formulate, you should think about the appropriateness of using this scenario in the overall process.

    It is important to realize that the formation of User stories implies the direct involvement of future consumers of the developed product in the process of its creation, making them co-authors (or partners in case of failure). And this fact must be used, by conveying to the consciousness of the customer, the need to share responsibility for the quality of the created product.

    It is convenient to write user stories on stickers pasted on a board, to which the entire project team has constant access. This venue is usually used for meetings - a joint discussion of the stages of the automation process of announced business scenarios. Making User Stories on the sticker ensures that it doesn't get too big.

    When the User story goes through the life cycle: formation, discussion, implementation, testing, etc., stickers with their descriptions are glued to different “paths” corresponding to the development stage. Thus, in small projects, using the described technique, they manage not only the content of the top-level project, but also the process of its implementation. I would recommend using this approach in large projects that use professional requirements management tools. This method has not only practical, but also great psychological significance, affecting the team spirit of the project. An example of a user story is shown in Figure 5.1.



    Fig. 5.1. User history

    User stories can also be effectively used for acceptance testing.

    Based on the goals identified above, we begin to collect and publish user stories (Functional Requirements).

    So, we need to develop a Software Product that will provide support for the following business processes:

    US01. Describe the user story on the sticker. Formulate the purpose of the process.
    Purpose: To fix the business process to be automated in a form that is accessible for discussion.


    “US01” - in this example, is the User History identifier, consisting of a prefix indicating the type of the project artifact (User Story) and its serial number. Add the term to the glossary:



    As a rule, the style of presentation and the content by users of their wishes for the product being developed, to put it mildly, is not ideal. Even showing these wishes to other team members, we are faced with a lack of understanding of the essence of the problem. Therefore, it is advisable to discuss each user story with interested participants and try to formulate it clearly and monosyllabic. We write it like this:

    US02. Discuss user history with project participants. Modify if necessary.
    Purpose: To familiarize the project team with the business process scenario. Align it.


    For further use of the User story, we need to fix it in the system. For example, by linking the User story with the corresponding requirements, we can trace its implementation in the final product through the chain: User story → Requirement created by it → Tasks set on demand, etc. We formulate:

    US03. Publish consistent user stories to the system.
    Purpose: To fix in the system a list of approved Business requirements for their accounting and processing.


    Since User stories are formulated by the author or a group of authors and present their view of the problems falling within the scope of their interests, we need to fix these “interested parties” in our system. For the development of any project, it is very important to determine the circle of people who are somehow interested in obtaining the target product. Based on this data, we will coordinate requirements, define user roles, etc.

    US04. Based on user stories, identify key project stakeholders.
    Purpose: To fix in the system a list of participants and stakeholders of the project.


    The user story does not give us reason to immediately start writing the program code, since this is just a definite look at the processes, in fact - declarations or drafts. First, they will need to be clarified, detailed, developed algorithms that clearly regulate the execution of processes, modeling the structure of objects in the subject area, etc. Therefore, having finished the process of fixing the main User stories, we proceed to the modeling of processes and objects that implement them. Along the way, we determine their connections and information flows. Let's put it this way:

    US05. Based on User stories, determine the basic functional requirements for the system being developed.
    Purpose: To fix in the system a list of business processes to be automated.


    After determining the full functionality of the product being developed, it often comes to the realization that it is not realistic to implement this entire list on time, with the available resources. And then, you need to divide the functions into: vital to support the process and the functions that are needed, but so far you can do without them. Having squeezed these thoughts into one sentence, we fix:

    US06. Based on the prepared list of automated processes, determine their priority and priority.
    Purpose: To determine the current boundaries of the project.


    When all the processes, classes, storages and other objects of the developed requirements are designed, it is necessary to "string" all this information on a single core, connecting the elements together: in notations, document descriptions and other artifacts. Such a core is usually the specification of requirements. They are recorded in the form of structured data, have a unique identifier, to which all of the above artifacts refer. Record the following User History:

    US07. Based on the processes identified for automation, formulate requirements specifications for their implementation in the product. Register requirements in the system, correlate with user stories.
    Purpose: To register in the system: content, conceptual content of the project content, wording of the essence of automated services that provide a basis for product development, testing and transfer to operation.


    When we develop specifications, we will get a complete list of low-level system requirements with a detailed description of their implementation. Based on this list, we will be able to submit tasks or task chains to performers for design, development, testing, deployment, pilot implementation, etc. When a task is set on demand, its state in the system can automatically change. Thus, in the list of specifications we can see which requirements are already taken into work, and which are still waiting in line. And since specifications are associated with User Stories, we’ll be able to track their status through the chain.

    US08. Based on the specification of the requirement, formulate tasks for the performers. During the execution of tasks, change the status of requirements.
    Purpose: Based on the requirements, to ensure the project implementation process in the target product.


    The task set for the contractor becomes available to him in the system. Since the task is set on demand, the contractor can familiarize himself with its specification, as well as the specifications of all requirements associated with it.

    Having completed the work, the contractor fixes a progress report, “closing” his tasks. Closing the task chain on demand automatically initiates a change in its state.

    US09. Record the fact that the contractor completed the task. Change the status of a request.
    Purpose: Based on the fact that the contractor completed the task, to ensure the updating of the project implementation process.


    Often, after the development of the first prototypes of the target product, users who have familiarized themselves with its work visit “insight”. They begin to clearly understand that they did not want “this” or not quite “this”. There is a need to amend the requirements. Despite its apparent simplicity, this is a very painstaking process that requires changes to be made through all the artifacts of the project. Sometimes, you have to make changes from the very beginning (fixing the User History) and then through all stages of the formation of the requirement.

    US10. Modify the specification requirements for implementation in the product. Change the status of a request. Synchronize with user history if necessary.
    Purpose: To change the content of the content that provides the basis for product development, its testing and transfer to operation.


    Since the Requirements management process is associated with constant monitoring of the degree of their implementation, it is necessary to have a convenient tool that allows you to select arrays of requirements for different sections of their properties, including current states.

    US11. Provide a complete or limited list of requirements with current status for different sections.
    Purpose: To obtain data on the current state of the development process of the target product of the project.


    In the course of project promotion we can: add new User stories; lay out approved stories, detailing them in a group directly involved in its implementation.

    2. WE USE VISUALIZATION OF REQUIREMENTS FOR DISCUSSION THEM WITH THE CUSTOMER


    Another effective technique of the discipline “System analysis” is modeling. Eric Evans in the book [13] positions the model as: “a language spoken by all members of the development team, and can also ... communicate with specialists in the subject area without a translator.” Therefore, the better we select a set of models for interaction with the customer and members of the project team, the closer and more productive our cooperation will be and, accordingly, the more fully and efficiently we can satisfy their needs.

    For clarity, you can display user stories in the form of models representing a set of related functions - scenarios on the diagrams of Business Communications. Unlike canonical diagrams, here you can display objects of different types in a relatively free form, thereby adding clarity.

    Let us give a definition of the model, since this is one of the key design elements:



    An example of a model for creating user stories is shown in Figure 5.2.



    Fig. 5.2. Scenario of the formation of the User story

    In the figure, we clearly see the processes, their sequence and place of execution, as well as resources.

    With the help of such drawings, it is easier for customers to represent the subject area and discuss the requirements for the developed product. But, passing the diagrams of this type to the interested parties, they should be accompanied by an oral, or better written description. For example, for the presentation of the above diagram, you can use the following text:

    In the central part of the figure, the business scenario “Formation of User History” is depicted. The script consists of four processes, mapped in the order in which they should be executed. The lower part shows the executors of the processes, the dashed line indicates their impact, and the inscription defines the role. In the upper part of the diagram, the locations of the processes are represented, and the lines indicate the data flows that pass through them.

    3. SUMMING UP THE PROCESS OF DETERMINING THE CUSTOMER'S NEEDS


    User stories, on the one hand, are an excellent mechanism for identifying user requirements, and on the other hand, they can be positioned as the main tool for customer influence on software development. Speaking User stories with project stakeholders on disputes, encourage people to repeatedly “lose” in their minds different scenarios of their work, and not only those that are currently used, but also those that they wanted to realize in the future.

    In flexible design methodologies - User history is used as a quick way to document customer requirements, without the need to develop extensive formalized documents and subsequently spend resources on maintaining them. But such an approach can only be successfully used for small or uncomplicated projects that are not related to “swirling” business processes that are not planned to be developed and maintained.

    I suggest using User Stories as the first step in the process of collecting and formalizing customer needs, to obtain a complete list of business tasks that can be automated by creating a software product. Further, these needs should be detailed and transformed into the functions of the target system.

    In the next part, we will identify the functions of the system and determine the boundaries of the project link

    List of references
    1. Jacobson A., Butch G., Rambo J. - “Unified Software Development Process” (2004)
    2. David A. Mark and Clement McGowan - “SADT Structural Analysis and Design Methodology”
    3. Cobern - “Modern Methods for the Description of Functional requirements ”(2002)
    4. Leffingwell Dean, Widrich Don -“ Principles of working with software requirements ”(2002)
    5. Karl I. Wigers -“ Development of software requirements ”(2002)
    6. Elizabeth Hall, Ken Jackson, Jeremy Dick - “Developing and Managing Requirements A Practical User Guide” (2005)
    7. Scott Ambler - “Flexible Technologies: Extreme Programming and the Unified Development Process ”(2005)
    8. Greenfield Jack, Kane Short -“ Software Development Factories ”(2007)
    9. Alistair Cowburn - “Each project has its own methodology”
    10. Wolfson Boris - “Flexible development methodologies”
    11. Leszek A. - “Analysis of requirements and system design”
    12. Freeman Eric, Freeman Elizabeth - “Design patterns” (2011)
    13 Evans Eric - “Subject-Oriented Design” (2011)
    14. GOST 34.602-89 “Information technology. Set of standards for automated systems. Terms of Reference for the creation of an automated system "

    Also popular now: