System Needs Analysis

Hello,
I understand that SA describes the customer expectations on the system, the expected services that have to be delivered in different usage contexts. The SA exhibits system need functions and external exchanges through the identification of the main interactions/collaborations of the actors with the system.
What needs to be clarified for me is the signification of the internal exchanges between those functions in terms of system needs, especially when internal functions are created to link transversal paths. Establishing communications between paths to mutualize need functions may help simplifying the system needs description. But then two questions come to mind:

  1. what is the meaning of the internal functional exchanges in terms of system needs (would they relate to system requirements)?
  2. Regarding internal functions with no external changes with actors, how should they be dealt with in terms of system requirements? What do they mean in terms of system needs? (They seem to be instrumental).
    Thank you in advance for your inputs on this topic.
    Best regards,
    Joel

Hello Joel,
Considering “transversal paths” as you say is a good way, among others, to start System Need Analysis; but there is no reason to stop there and restrict to functions directly and only linked to external actors functions. This usually results in a more complex, less readable and less expressive model.
To try an example, consider a video capture drone, with the following user requirements:
“the system shall record the video in real time”
“the system shall allow defining a ground user-defined location”
“the system shall steer the camera towards the user-defined location on demand; the line of sight precision should be xxx degrees”.
For me, the most natural and simple way to model this at need (SA) level would be:

  • to create system functions such as ‘capture video’, ‘record video’, ‘define ground location’, ‘steer camera’;
  • to link them by exchanges such as ‘live video’, ‘ground location’, ‘line of sight’, directly linking these functions, without necessarily intermediate actors functions (see diagram).
    Requirements can be linked to any function or exchange, e.g. “the system shall steer the camera towards the user-defined location on demand” will be translated by ‘steer camera’ function and ‘line of sight’ exchange; this exchange will likely be linked to “the line of sight precision should be xxx degrees”.
    Can you imagine a simpler way to deal with this need, considering only ‘transversal paths’ ?

Hi Jean-Luc,
In your example, all the function involved is linked to an external actor.
Following your example : “the system shall record the video in real-time”
Assuming that it is the principal requirement of a drone.
In order to realize this requirement, we are obliged to initialize our system before starting the record.
do we consider at system level this initialization phase (in this case the function is not linked to the external actor)? Do we have a specific scenario at the system level? Beside, according to the technologies involved, scenarios would not be the same.

You are right, my example is weak for the purpose of my argument (and even beyond
).
Let’s try to improve it a bit (see new diagram below, please be indulgent!) : I added two new requirements:
“the ground location shall be the center of an image selected in real time by the user”
“the video shall be stabilized”.
In this case, the ‘stabilize video’ and ‘steer camera’ functions seem to have no external actor interaction - well, I hope so.
(of course, you might argue that steering should be cancelable, so you would ask the customer, himself replying “the user will select either manual steering or ground location steering on demand”, so you would likely add a new function to interact with user and manage these two “modes” and select one of the two ‘line of sight’ exchanges towards ‘capture video’… and so on. I stop here!).
Note that steering requires position and orientation information to be effective, but this is not mentioned here because not part of the need (not a service expected by the user), but rather of solution (logical or physical architecture definition).
Similarly, for me, initialization phase is a design concern, so I would not mention it in system need analysis.
Anyway, hopefully this simplistic example shows how much formalizing via models enriches engineering with questions that might not have appeared otherwise.

Hello Jean-Luc, hello Régis,
Thanks for your inputs ! Just a little push to fully grasp the distinction between a need function and a solution function (and to devise how to adequately model those two kinds of functions in Capella). If we are to use models in order to help formalizing system’s documentation such as system requirements documents, there has to be some recommendations to help on that.
First, I believe we agree that “System Needs Analysis” is the thinking process which results in exhibiting the system of interest required services and their related quality attributes. Those services correspond to sets of interactions between external systems/actors and the system of interest; interactions which are answers to some stakeholders needs (an operational activity or a constraint).
Considering the drone example, stakeholders needs could be:

  1. The user shall be able to inspect a designated zone on video records.
  2. The user shall be able to define the ground location to inspect.
  3. The user imposes that the designated ground-location shall be the center of the recorded images.
  4. The user imposes that the video is stabilized (or any constraint regarding the quality of the images allowing an effective inspection).
    (There are obviously other needs pertaining to operability, availability, security/safety, evolutivity/durability,…)
    From those needs, system’s requirements have to be formalized: the envisionned contribution of the system which may be captured via use-cases and related scenarios. The “functional footprint” of the use-cases on the system will exhibit the functions required from the system in order to enable the use-cases. By design, those functions have systematically interactions with external systems (at least, the functions associated to required capabilities). Functions with no interactions with external actors might stem from constraints: that is the case for the “stabilize video” and “steer the camera” functions. There may be a pattern here.
    More globally, formalizing system requirements is a difficult task, and often requirements documents are written as design documents. SA shall help avoiding that. Unfortunately, in the field, more often than not, the boundary between SAB and LAB is blurred and we can get so-called “need functions” that are mostly internal (the interaction with the environment is limited to the display of information). And, moreover, each function and each functional exchange are materialized as requirements (“upon reception of the functional exchange xxx, the function provides yyy”)… Not very sure that is the spirit of the SA.
    What do you reckon?
    Joel

Hello Jean-Luc, hello Régis,
Thanks for your inputs ! Just a little push to fully grasp the distinction between a need function and a solution function (and to devise how to adequately model those two kinds of functions in Capella). If we are to use models in order to help formalizing system’s documentation such as system requirements documents, there has to be some recommendations to help on that.
First, I believe we agree that “System Needs Analysis” is the thinking process which results in exhibiting the system of interest required services and their related quality attributes. Those services correspond to sets of interactions between external systems/actors and the system of interest; interactions which are answers to some stakeholders needs (an operational activity or a constraint).
Considering the drone example, stakeholders needs could be:

  1. The user shall be able to inspect a designated zone on video records.
  2. The user shall be able to define the ground location to inspect.
  3. The user imposes that the designated ground-location shall be the center of the recorded images.
  4. The user imposes that the video is stabilized (or any constraint regarding the quality of the images allowing an effective inspection).
    (There are obviously other needs pertaining to operability, availability, security/safety, evolutivity/durability,…)
    From those needs, system’s requirements have to be formalized: the envisioned contribution of the system which may be captured via use-cases and related scenarios. The “functional footprint” of the use-cases on the system will exhibit the functions required from the system in order to enable the use-cases. By design, those functions have systematically interactions with external systems (at least, the functions associated to required capabilities). Functions with no interactions with external actors might stem from constraints: that is the case for the “stabilize video” and “steer the camera” functions. There may be a pattern here.
    More globally, formalizing system requirements is a difficult task, and often requirements documents are written as design documents. SA shall help avoiding that. Unfortunately, in the field, more often than not, the boundary between SAB and LAB is blurred and we can get so-called “need functions” that are mostly internal (the interaction with the environment is limited to the display of information). And, moreover, each function and each functional exchange are materialized as requirements (“upon reception of the functional exchange xxx, the function yyy provides zzz”)… Not very sure that is the spirit of the SA.
    What do you reckon?
    Joel

We have the same experience of people mixing need and solution (even in purely textual requirements !), unfortunately.
In my opinion, the only way to avoid this is education and training.
For example by analyzing with them “good” and “wrong” need captures and emphasizing what is solution-oriented in them;
or by checking that each part of this need capture is clearly related to/derived from a user or customer need : either translation of one or more user requirements, or expressing the part of an operational activity attributed to the system, etc.
If this is well understood, then I believe that there is no need for extra “syntactic or grammatical rules” such as “no need function without a link with external actors”, or so. The simplest way to describe is always the best, and usually this kind of rules neither help in keeping it simple, nor really prevent from putting solution in SA.
Regarding using “textual requirements” to describe need functions, as you mention, this is not a problem for me, if this means explaining what the function shall do or deliver, as needed. Textual language is still the most natural way for people to translate what they have in mind, and to capture what another stakeholder thinks/needs.
These kinds of “textual requirements” should be used to detail expectations on each model element needing explanations, such as functions, but also data, possibly exchanges, functional chains and scenarios as a whole, and also parts of the latters (e.g. to express a latency on a functional chain; or to express what is expected from a function involved in a functional chain). But they must be focused and limited to the sole elements to which they relate.

Copyright © Eclipse Capella, the Eclipse Capella logo, Eclipse and the Eclipse logo are Trademarks of The Eclipse Foundation.