Definition of the requirements formulation process. Documentation of the stages of detection, analysis, definition and verification requirements. Availability of instructions for performing key operations will help analysts perform their work in a quality and consistent manner. In addition, it will be easier to set the tasks for creating requirements and schedules, as well as to consider the necessary resources.
Definition of the image and boundaries of the project. image document and The project boundary contains the business requirements for the product. Description image of the project will allow all interested parties in general terms understand the purpose of the product. Project boundaries define what should be implement in this version, and what – in the next. The image and boundaries of the project – a good basis for evaluating the proposed requirements, Product Image should remain relatively stable from version to version, but for each issue must be a separate document on borders.
Definition of user classes and their characteristics. To not to lose sight of the needs of individual users, it is necessary combine them into groups. For example, by the frequency of working with software, features used, privilege level, and job skills. A description of their duties, location and personal characteristics that can affect the architecture of the product.
Choice of a product champion in each class users. This is a person who can accurately conveycustomer sentiment and needs. He represents the needs a certain class of users and makes decisions on their behalf. At development of internal corporate information systems, when all users are your colleagues, it is easier to choose such a person. For commercial development, ask clients or use beta test sites. The people you choose must accept permanent participation in the project and have the authority to take decisions regarding user requirements.
Creation of focus groups of typical users. Determine groups of typical users of previous versions of your product or similar. Ask them for details about the functionality and quality characteristics of the developed product. Focus groups are especially important in the development of commercial products, when you have to deal with a large and diverse client base. Unlike product advocates, focus groups usually do not have decision-making authority.
Work with users to clarify the purpose of the product. Ask users what tasks they need to perform software means. Discuss how the client should interact with system to perform each such task. Take advantage standard template for documenting all tasks and for each formulate functional requirements. In a similar way, often used in government projects is to create a document with concepts of operations (ConOps), which specifies the characteristics of the new systems from the user’s point of view (IEEE, 1998a).
Definition of system events and reaction to them. Determine possible external events and the expected response of the system to them. This may be signals and data received from external equipment, and also temporary events that cause a response, for example nightly transmission of data generated by the system to an external object. In business applications, business events are directly related to tasks.
Conducting joint seminars. Joint seminars on identifying requirements where analysts and customers work closely together – great way to identify user needs and sketch requirements documents (Gottesdiener, 2002). Specific examples such seminars – Joint Requirements Planning (JRP – joint requirements planning) (Martin, 1991) and Joint Application Development (JAD stands for Collaborative Application Development) (Wood and Silver, 1995).
Monitoring users in the workplace. Watching over the work of users, reveal the context of potential application new product (Beyer and Holtzblatt, 1998). Simple Worker Diagrams flows, as well as data flow diagrams allow you to find out where, how and what data the user used. Documenting the move business process, it is possible to determine the requirements for the system designed to support this process. Sometimes even it turns out that in order to perform business tasks, customers do not need to new software required (McGraw and Harbison, 1997).
Examining problem reports from running systems to improve search for new ideas. Problem reports from customers and feature enhancement suggestions are a great source: ideas about features that can be implemented in the next version or a new product. For such information, please contact support staff.
Reuse requirements across projects. If the functionality required by the client is similar to that already implemented in a different product, consider whether customers are willing to flexibly reconsider your requirements for using existing components. Requirements that comply with the company’s business rules can be apply to multiple projects. These are the security requirements defining the order of access to applications, and requirements, compliant with government regulations, such as the Law on US citizens with disabilities (Americans with Disability Act).
Requirements analysis
Creating a context diagram. Context Diagram − a simple analysis model showing the place of the new system in appropriate environment. It defines the boundaries and interfaces between developed by the system and entities external to this system, such as users, devices and other information systems.
Creation of user interface and technical prototypes. If developers or users are not entirely sure about requirements, create a prototype – partial, possible or a preliminary version of the product, which will make the concepts and opportunities are more tangible. Prototype Evaluation Helps Everyone interested parties to reach an understanding on the problem.
Feasibility analysis of requirements. Analyze, how realistic it is to implement each requirement with reasonable cost and with acceptable performance in the intended environment. Consider the risks associated with implementing each requirement, including conflicts with other requirements, dependence on external factors and obstacles of a technical nature.
Determination of requirements priorities. Take advantage analytical approach and determine relative priorities implementation of product functions, tasks to be solved or individual requirements. Based on priorities, decide which version will have a particular function or set of requirements is implemented. Confirming changes, allocate all of them to specific versions and include them in release plan for these versions costs required to make changes. During the course of the project, periodically adjust the priorities in according to customer needs, market conditions and business goals.
Requirements modeling. Unlike detailed information provided in the software requirements specification, or user interface prototype, graphic model analysis displays requirements at a high level of abstraction. Models allow you to identify incorrect, inconsistent, missing and redundant requirements. These models include flow diagrams data, entity-relationship diagrams, state transition diagrams, also called automata (statecharts), dialog maps, diagrams classes, sequence diagrams, interaction diagrams, decision tables and decision trees.
Creation of a dictionary of terms. In it, collect the definitions of all elements and data structures associated with the system, allowing everyone project participants to use agreed data definitions. At the stage of work on the requirements, the dictionary should contain definitions of data elements related to the subject area, to make it easier for customers and developers to communicate.
Distribution of requirements by subsystems. Requirements to a complex product that includes several subsystems should proportionately distributed between software, hardware and operator subsystems and components (Nelsen, 1990). As this is typically done by a systems engineer or developer.
Application of quality function deployment technologies. Quality Function Deployment Technology Deployment, QFD) is an accurate technique that correlates capabilities and product attributes with their relevance to the customer (Zultner, 1993; Pardee, 1996). It allows you to analytically identify the functions that best meet the needs of the client. Technology The deployment of quality functions is designed for three classes of requirements: expected, which the client may not mention, but will be upset, if they do not appear in the product, the usual requirements and individual, special requirements that ensure comfortable operation clients, but the absence of which does not entail sanctions on the part of the client.