Step 1 Requirements Engineering

Introduction

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.

Activities - Phase 2

The activities below will occur in parallel and iteratively with Step 2.

Navigation Links

• Back to Systems Engineering Lifecycle Main Page
• Back to ISO 29110 Lifecycle Main Page
• Back to Polarsys Autonomous Rover Case Study Main Page