The objectives of a project will determine your needs and act as a filter.
The set of requirements is what defines the scope of the project.
Technical specifications for each requirement will be created with the functions to be accessed and tested and to be delivered as a result of the project.
The functional requirements are the requirements of what the project should enable to obtain and perform functions that should allow.
The non-functional requirements are not explicit in the project but nevertheless they are to be achieved and may be the level of performance, ease of use, robustness, security, legal, operational or other.
Interested parties (stakeholders) are an integral part of the project. Since end users and experts to any person who is benefited by the project.
End-users in particular will know who more easily assess the value of the project.
Are experts who can provide support on existing more specific questions.
The requirements capture involves the use of questionnaires and interviews with stakeholders in order to understand what is intended. Sometimes it may also involve observing users.
Questionnaires are an effective way to collect a broad set of information. However, if the right questions are not made not get the correct answers. Also do not provide a way to clarify questions or resolve conflicts.
Interviews can take as its point of departure a questionnaire but allow a more open discussion of project requirements. The interviews take longer and involve more people, especially if done in a group or with various stakeholders.
It is customary to combine the use of interviews and questionnaires.
As the project grows in complexity increases the need to specify and document the requirements. It is customary to have a signature from the interested party of the requirements identified.
The documentation requirements going beyond the point of view of users should try to show what the main objectives to be achieved by the project.
The documentation should cover both the decisions taken and the reasons for the same have been taken.
A simple specification of requirements without any discussion of what is wanted can be difficult to understand for end-users.
Requirements has several audiences. Will be used by the project group to deliver the project but also by the various interested to see what is being done.Contextual information for ilustar the reasons behind a decision is helpful but the discussion of the statements should be separated.
Some basic rules are:
For each requiremento there should be a statement and decision All claims should be a simple sentence using “must” or “should” “Must” indicates a necessary requirement. “Should” denotes an optional requirement.
There must be a visual way to distinguish between assertion and discussion.
The change control requirements that will going over a project is essential to ensure that the project proceed as planned.
Traceability is one of the most onerous burdens associated with project management.
Traceability allows, even if you have a project with hundreds or thousands of requirements understand how the specification of any requirement passed for the design, development, testing and launch.
It is through traceability which can prove that the initial requirement was satisfied.
On large projects a requirement may be satisfied by various elements and secondly an element can fulfill various requirements increasing the complexity of management.