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:
what is the meaning of the internal functional exchanges in terms of system needs (would they relate to system requirements)?
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.
The user shall be able to inspect a designated zone on video records.
The user shall be able to define the ground location to inspect.
The user imposes that the designated ground-location shall be the center of the recorded images.
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
The user shall be able to inspect a designated zone on video records.
The user shall be able to define the ground location to inspect.
The user imposes that the designated ground-location shall be the center of the recorded images.
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.
Not only in the field, but also in theory (as this discussion aptly demonstrates the distinction between a need and a solution is often more than blurred. E.g. what about âsystem requirementsâ steming from existing legacy solutions that âneedâ to be reused to implement teh stakeholder requirements. It is always possible to ask the question about alternatives : if stakeholders requirements (the actual, true requirements) could be fullfilled in a way which is different to what a âsystem requirementâ postulates. If the answer is yes, that the latter is a particular solution or a constrain to it, but not a requirement. If you not agree, then you are simply confirming that each âsystem requirementâ as a alternative to fullfill a stakeholder requirement has an element of solution (i.e. the alternative) in it. To resolve this semantic ambiguity I try to avoid the term âsystem requirementâ in favor of e.g. system constraint.
Maybe part of the ambiguity lies in the target of âneed definitionâ or âsolution definitionâ, on one side, and on what we usually (but maybe wrongly) associate with âsolution definition or designâ, on another side.
It is true that when shaping the need (i.e. what the customer/users want the solution to provide them), we may have to consider different ways to express and formalise it, and even different alternatives of what is needed.
So definitely, there is some creativity and decisions involved here. Some will even speak about âdesignâ, because the intellectual processes are similar (to some extent) - hence the use of functional analysis for both need and solution definition.
But in any case, this would be âa design of customer/users needâ, not a design of the solution, which is a different affair, dealing with âthe design of how the solution will be developped and built so as to fulfil the needâ.
To try to summarise and hopefully conclude, Need definition and Solution definition are two processes sharing some practices and approaches, but they have different targets and purposes.
Hi All
This thread is quite long and to be honest I did not read all in detail, but still I give my point of view:
A function is a requirement made to a component to convert received items into other ready for delivery or deliver them. Thus, to me no functional exchange should run within the system, as the customer knows only external exchanges.
If we donât want to have one big function doing all, we create several parallel function that tend to be represented in one scenario only, each can require same entries than some others and produces same items than some others. Doing this multiplies the FE, but they are still allocated by the same component exchange.
The time to reorganise and make a more rational inner functional picture is Logical Architecture: Sort function by activity requirement during component (system) modes or even variant, mutualize inputs and organize multi step deliveries for instance, or set physical domain change boundaries.
Then, physical architecture is when you try to link each LC (transitioned into BPC) to a designed component (mentioned by NPC), and check against your physical architecture about PL availability to support your component exchangesâŠ
Hi @JVoirin, I cant seem to view your diagrams in post, they donât show for me. Is there a specific location where I can view images attached to your responses? A lot of your responses have âsee diagramâ, and I would really like to view those to help with model development choices on my current project =]. Cheers!
the distinction between a need and a solution is often more than blurred. E.g. what about âsystem requirementsâ steming from existing legacy solutions that âneedâ to be reused to implement teh stakeholder requirements. It is always possible to ask the question about alternatives : if stakeholders requirements (the actual, true requirements) could be fullfilled in a way which is different to what a âsystem requirementâ postulates. If the answer is yes, that the latter is a particular solution or a constrain to it, but not a requirement. If you not agree, then you are simply confirming that each âsystem requirementâ as a alternative to fullfill a stakeholder requirement has an element of solution (i.e. the alternative) in it. To resolve this semantic ambiguity I try to avoid the term âsystem requirementâ in favor of e.g. system constraint.