Step 1 Requirements Engineering
- 1 Introduction
- 2 Activities - Phase 1
- 2.1 SR.1.1 – Review Project Plan with the Work Team members
- 2.2 SR.2.1 - Elicit Acquirer and other stakeholders requirements and analyze system context
- 2.3 SR.2.2 - Review Stakeholders Requirements Specifications with PM
- 2.4 SR.2.3 - Baseline Stakeholders Requirements Specification with the Acquirer and Stakeholders
- 2.5 SR.2.4 - Capture System Requirements and Interfaces
- 2.6 SR.2.6a - Verify and obtain Work Team (WT) agreement on the System Requirements Specification
- 2.7 SR.2.7 - Validate that System Requirements Specification satisfies Stakeholders Requirements Specification
- 2.8 SR.2.8a - Define or update traceability between Requirements (System to Stakeholder)
- 3 Activities - Phase 2
- 4 Navigation Links
In requirements-driven development, this step is without a doubt the most critical of them all. This is that time when the team makes first contact with the Acquirer and Stakeholders and gets to get a first shot at finding out what the stakeholder needs are define the system<s requirements.
Activities - Phase 1
The activities below are defined and described in the Requirements Engineering DP.
SR.1.1 – Review Project Plan with the Work Team members
Prerequisites: From the Project Management DP, the Project Planning process (PM 1) and Step 1 (Obtain agreement on project plan) of the Project Execution process (PM 2) have been completed successfully.
The Team Leader distributes the Project Plan, convenes and holds the Requirements Analysis Kick-off to review the Project Plan, task assignments and raise any issues for the Work Team as to needed revisions to the Project Plan.
For this project, the Team Leader informs the Team that they will have access during the project to the following stakeholders:
- the Purchasing Agent of the Emergency Response Service. This person is also the Acquirer;
- the Emergency Response Squad Leader represents the primary users of the Autonomous Rover;
- the Maintenance Technician of the Emergency Response Squad is another primary stakeholder; and
- a Firefighter from the local Fire Station represents the seconday stakeholders and the main end-user of the information the Autonomous Rover will develop.
The Team Leader is also happy to inform the Team that the Acquirer has supplied two documents for the Team to work with:
- an Operational Concept (OpsCon) draft document. This document will serve as the main input to identify Stakeholder Requirements; and
- a draft System Requirements Specification for the Autonomous Rover.
Both documents can be retrieved from the GitHub repository, from the Step01/Entry/Docs folder.
The Team Leader confirms the following: - Stakeholder, System and System Element requirements and traceability links will be captured using the Eclipse Requirements Management Framework (RMF); - the textual System Requirements will be validated using the Use Case Analysis methodology iton Papyrus SysML; - each Use Case will be traced to the System Requirements it covers using Proxy links between RMF and Papyrus; - the Logical and Physical Architecture will be modeled in Papyrus SysML using the Block Definition Diagram (BBD) and Internal Block Diagram (IBD)
SR.2.1 - Elicit Acquirer and other stakeholders requirements and analyze system context
Prior to the start of this activity, you must have installed Eclipse RMF application. The Eclipse RMF/ProR can be used, or you can use one the RMF-based distributions available.
In the GitHub project repository, two documents, in LibreOffice format, provide the Stakeholder's Requirements and a draft System Specification that form the basis of the activities performed in this step. YourGitHubRepository\ISO29110-Polarsys-Rover\Step 1 - Requirements Engineering\SR1_1\Docs
The two documents are also available as a RMF ReqIF repository in the same folder.
SR.2.2 - Review Stakeholders Requirements Specifications with PM
SR.2.3 - Baseline Stakeholders Requirements Specification with the Acquirer and Stakeholders
SR.2.4 - Capture System Requirements and Interfaces
SR.2.6a - Verify and obtain Work Team (WT) agreement on the System Requirements Specification
SR.2.7 - Validate that System Requirements Specification satisfies Stakeholders Requirements Specification
SR.2.8a - Define or update traceability between Requirements (System to Stakeholder)
Activities - Phase 2
The activities below will occur in parallel and iteratively with Step 2.