Using the Software Requirements Specification Template. Create a standard template for documenting software requirements in your organization. The template provides a consistent structure, allowing you to fix descriptions of the desired functionality, and as well as other information regarding requirements. Instead of to invent a new pattern, modify one of existing in accordance with the specifics of the project.
Many companies start by using the requirements specification template to the software described in IEEE 830-1998 (IEEE, 1998b). If your company is engaged in various projects, for example, designs a new large application and in parallel refines versions of old programs, create appropriate templates for all types of projects. Templates and processes should be scalable.
Determination of sources of requirements. To ensure that all stakeholders understand, for some reason or another requirement fixed in the software requirements specification, and simplify subsequent clarification of requirements, identify the sources of all requirements. It could be a use case or another information from users, high level system requirement, business rule or other external factor. Listing all persons interested in every requirement, you will know to whom contact when requesting a change. Sources requirements are established on the basis of relationships or determined for this goal attribute of the requirement.
Assigning unique identifiers to all requirements. Develop a convention for assigning unique identifiers requirements specified in the software requirements specification. The agreement must be resistant to additions, deletions elements and changes to the requirements. Assignment identifiers allows you to track requirements and capture the changes being made.
Specifying quality attributes. By identifying quality features that meet customer needs limit yourself to discussing functionality. find out expected performance, efficiency, reliability, user-friendliness use other information from clients about relative importance certain qualitative characteristics will allow the developer make the right decisions regarding the architecture of the application.
Documenting business rules. The business rules are corporate policies, government regulations and calculation algorithms. Maintain a list of business rules separately from software requirements specifications because rules usually exist outside of a specific project. Some have to be done in order to create functional requirements that implement them, and therefore it is necessary to determine the relationship between these requirements and relevant rules.
Requirements check
Studying documents with requirements. official verification documenting requirements is one of the most valuable ways software quality checks. Assemble a small team whose members represent different areas (for example, analyst, client, developer and tester}, and study carefully software requirements specification, analysis model and related information about deficiencies. It is also useful to carry out during formulating requirements their informal preliminary viewing. And although it is not easy to implement this in practice, this technique – one of the most valuable, so start implementing requirements checking in your organization right now. Requirements testing. Based on custom requirements, create functional test scripts and document the expected behavior of the product in specific conditions. Explore test scenarios with customers and make sure they reflect the desired behavior of the system. Trace linking test scenarios to functional requirements, and make sure that no requirement is missing and that for all requirements there are corresponding test scenarios. Run scenarios to make sure the analysis models are correct and prototypes.
Definition of acceptance criteria. Suggest describe to users how they intend to determine compliance product to their needs and its suitability for the job. Tests for acceptability should be based on use cases.
Requirements Management
Define the change management process. Determine the process of presenting, reviewing and approving or rejecting changes. Use it to manage all the offered changes. In the context of the change management process, it is useful use commercial flaw tracking tools.
Establishment of a change management board. From representatives stakeholders in the project organize a management council changes, which will receive information about the proposed changes in requirements, evaluate it, decide what changes to accept, and which ones to reject, and determine which version of the product will be implemented one function or another.
Analysis of the impact of changes in requirements. Impact Analysis changes helps the change management board to make informed decisions. Assess how each proposed change requirements will affect the project. Based on the relationship matrix, identify other requirements, architecture elements, source code and scripts testing that may need to be changed. Define what necessary to implement the change, and estimate the cost of implementation.
Baseline creation and requirements versioning. The base version contains the requirements approved for implementation in specific version of the product. After defining the basic requirements changes can only be made in accordance with the control process changes. Assign all versions of the requirements specification unique identifiers to avoid confusion between draft versions and base versions, as well as between the previous and current versions of the requirements. A More Reliable Solution – Manage versions of documents with requirements using appropriate configuration controls.
Keeping a log of requirements changes. Fix dates requirements specification changes, the adjustments themselves, their reasons, and as well as those who made the changes. Automate these tasks allows version control utility or commercial utility requirements management.
Monitoring the status of all requirements. Create a database including one entry for each discrete functional requirement. Enter the key attributes in the database each requirement, including its status (e.g. “proposed”, “approved”, “implemented” or “verified”) so that at any time you could find out the number of requirements in each state.
Evaluation of the variability of requirements. Record weekly the number of requirements included in the base version, as well as the number proposed and approved changes (additions, modifications and deletions). If the requirements are formed not by the client, but from his faces, it may turn out that the problem is poorly understood, the boundaries of the project not clearly defined, the business is rapidly changing, while collecting information, many requirements have been omitted or internal corporate policies are changing for the worse.
Use of requirements management tools. Commercial requirements management utilities allow you to store different types of requirements in the database. For every requirement, you can identify attributes, track its status, and identify relationships between requirements and other work products. This technique helps you automate other management tasks the requirements described below.
Creating a matrix of requirements links. Create a table matching all functional requirements with elements architectures and code that implement this requirement, and with tests, checking it. The requirements relationship matrix also allows compare functional requirements with those of higher levels on the basis of which they are created, and with other related requirements. Fill in this table at the entrance, and not at the end of work on project.