Arcadia & ISO/IEC/IEEE 29148 Requirements Engineering

Arcadia
1

The ISO/IEC/IEEE 29148 standard (Systems and software engineering – Life cycle processes – Requirements engineering) defines the following requirements engineering processes:

  • Stakeholder requirements definition process
  • Requirements analysis process (System Requirements, SyRS)
  • Software requirements analysis process (Software Requirements, SRS)
    And the following outputs :
  • Stakeholder requirements specification document (StRS)
  • System requirements specification document (SyRS)
  • Software requirements specification document (SRS), if adhering to ISO/IEC 12207.
    When trying to map expected outputs to Arcadia engineering phases, I was tempted to make the following correspondance :
  • OA ==> StRS
  • SA ==> SyRS
    Which is in accordance with the methodological support in Capella: OA “Define Stakeholders needs” and SA “Formalize System Requirements”.
    However, page 34 of Aradia guide tells me that the Functional Need Analysis (SA?) is related to the StRS output in Requirements Management, and that SyRS/SRS are related to LA and PA. So my first question is :
    is this a bug in documentation or are you trying to say something more ?
    Furthermore, when reading the ISO 29148 standard, it is not clear to me that the OA would be the engineering phase in which the StRS is produced. It could be also produced using SA artefacts if the system is considered as a grey-box in which only the main functions are defined and they are related to higher level capabilities and missions which are related to external actors. So my second question is :
    can we produce StRS with SA artefacts ?
    Finally, my third question is rather general :
    have you built a cartography of Arcadia wrt ISO15288 and ISO29148 standards, as you have made wrt to DoDAF and SysML ?
    Thank you in advance.
2

Hello Juan,
Practices may vary according to each context, so I will describe here our own practice, but the method could deal with others.
To be short, your understanding is correct
.
Arcadia Operational Analysis (OA) appears to address 29148 Stakeholder requirements definition process:
it defines Stakeholders, environment, business goals, business operational scenarios, processes…;
this is usually formalized in what we call an Operational Concept Document (OCD).
Among other outputs, it may also produce User Requirements, as described below.
This should be built together with the customer, although in most cases today, the customer only delivers UR as a unique input.
Arcadia System Need Analysis (SA) addresses Requirements analysis process:
it defines System purpose, context, scope, functions, interfaces, modes & states…
Usually, the major customer input is a set of User Requirements (UR) describing his need (this looks not so far from your Stakeholders requirements). This is often a contractual input coming from the customer, as a basis for technical contract.
This input is analyzed in Arcadia SA, in order to produce the functional/non functional need analysis. Each element of the SA model can be linked to some UR, for traceability/justification purpose.
This process may lead to creating new requirements, either because they need to detail or precise UR a bit more, or because they have been negociated with customer… This constitutes the System Requirements (SR), which are a kind of “answer” to the customer need, and, along with the SA model to which they are linked as well, finalise what is to be done.
The resulting document, based on SA and SR, is a System Segment Specification (SSS), similar to your SyRS.
Page 34 of Arcadia guide (thanks for reading it !) might be confusing, you are right: it is to be read from left to right at each method level, intending ‘take reqs as an input, then produce functional analysis, and allocate functions to components’; of course, this may lead to producing or refining requirements for the next level (and back to the left of the slide).
To answer your last questions:
“can we produce StRS with SA artefacts ?” Of course, you are fully free to use any method or model artifact to produce any document, according to your stakeholders expectations. But from a methodological point of view, if I understand clearly what StRS elaboration is for 29148, I would say that you should keep the system out of your StRS, in the same way as Arcadia recommends not introducing it in OA, but rather in SA. This would help in concentrating on users needs, goals, interactions, business processes…, without being polluted by a system-centric view, which might introduce bias.
“have you built a cartography of Arcadia wrt ISO15288 and ISO29148 standards, as you have made wrt to DoDAF and SysML ?” No, we did not, and we have currently no plan to do so, because of other priorities.