The goal of requirements analysis in projects is to get the maximum information about the customer and the specifics of his tasks, clarify the scope of the project, assess possible risks, as well as form a project team to which will be entrusted with a significant part of the forthcoming work.

At this stage, the key methodological and technological requirements, the goals and objectives of the project are formulated, and the critical success factors that will subsequently be used to evaluate implementation results. Requirements analysis carried out on the basis of meetings and interviews with managers and by the customer’s specialists, and the duration of this stage, in depending on the complexity of the tasks and the scale of implementation, range from several days to several weeks.

Definition and description of requirements (methodological and technical) – steps that largely determine the success of all project, because they affect all other stages. Practice shows that insufficient development of requirements often manifests itself only when the project is almost completed, and a significant part of the resources allocated for its implementation is already spent. Unfortunately, troubleshooting during the development phase is much more expensive than careful elaboration at the analysis stage.

Requirements Interpretation Features

IEEE Standard Glossary of Software Engineering Terminology (1990) defines requirements as:

1. Conditions or features required by the user for solving problems or achieving goals;

2. Conditions or capabilities that the system must have or system components to fulfill a contract or meet standards, specifications, or other formal documents;

3. Documented representation of conditions or opportunities for items 1 and 2.

This definition covers the requirements of both users (external behavior of the system) and developers (some hidden parameters). The term users should be extended to include all stakeholders, since not everyone who is interested in the project is users.

Requirements are the specification of what should be implemented. They describe the behavior of the system, the properties of the system, or her attributes. They may be limited by the development process systems.

Requirements levels. Three levels of software requirements:

– business requirements;

– user requirements;

– functional requirements.

Requirements types

Each system has its own functional and non-functional requirements.

Business requirements contain high-level goals of the organization or customers of the system. As as a rule, they are expressed by those who finance the project, buyers systems, real user manager, marketing department. Business requirements are formulated in a document about the image and boundaries of the project – project charter or market requirements document (market requirements document). Determining the scope of the project represents the first stage of managing common problems spreading borders.

User requirements describe goals and tasks that the system will allow users to solve. To excellent ways of presenting this type of requirements include options usage, scenarios, and event-response tables. Thus, This document specifies what customers will be able to do with systems.

Functional requirements define the functionality of the software that developers must build so that users can complete their tasks within business requirements. Sometimes referred to as behavior requirements (behavioral requirements), they contain provisions with the traditional “should” or “should”: “The system must e-mail send an order confirmation to the user.

The term system requirements denote high-level product requirements that contain many subsystems, i.e. a system (IEEE, 1998c). Speaking of the system, we means software or software subsystems and equipment. People are part of the system, so certain functions systems can extend to people.

Business rules (business rules) include corporate policies, government regulations, industry standards and computational algorithms. Business rules are not software requirements because they are outside the boundaries of any software systems. However, they often impose restrictions on who can fulfill specific use cases, or dictate what functions should a system that obeys the relevant rules. Sometimes business rules become source of quality attributes that are implemented in functionality. Therefore, you can track the origin of specific functional requirements up to their respective business rules.

Non-functional requirements contain goals and attributes quality. Quality attributes are an additional description of the product’s functions, expressed in terms of a description of its characteristics that are important to users or developers. These characteristics include lightness and simplicity use, ease of movement, integrity, efficiency and failure tolerance. Other non-functional requirements describe external interactions between the system and the outside world, and design and implementation limitations. Constraints concern choosing the possibility of developing the appearance and structure of the product.

The requirements specification does not contain design details or implementation (other than known limitations), planning data project or testing information.

Requirements Formulation Techniques

Requirements analyst training. To all team members, who will perform the functions of analysts, it is necessary to learn requirements formulation techniques – this can take several days. A skilled requirements analyst is patient and methodical, Possesses interpersonal and communication skills skills, knowledgeable in the subject area and knows many ways formulation of software requirements.

Familiarize users and managers with the requirements. Users who will take part in software development, must undergo a short training (one or two days) in order to learn to formulate requirements. It is also useful for managers development and customer service. Learning will help you understand the importance of identifying requirements, the essence of the process of their development, as well as danger of neglecting them. By attending my workshops on requirements, some users noticed that they became warmer towards software developers.

Familiarizing developers with the concepts of subject matter areas. To help developers understand subject area, hold a workshop where you introduce them to the client’s business, terminology and purpose of the product being created. This will reduce the likelihood of confusion, misunderstanding and improvements. Can also, for the duration of the project, assign each developer a “personal user”, which will explain professional terms and business concepts. It is better if it is a real fan of the product.

Creation of a business dictionary. Dictionary with specialized terms from the subject area will reduce the likelihood of misunderstanding, include synonyms, terms with multiple meanings, and terms that are different in the subject area and everyday life values.