Requirements

Requirement diagrams

Requirements represent goals or anti-goals that a system, once implemented, should satisfy. Requirements and relations between requirements are captured with SysML Requirement Diagrams. The latter are presented below, taking as example the Pressure Controller.

1. Open the slides on Modeling in SysML


2. Watch the video on Requirements


3. Find the latest SysML specification in the OMG website. Download this specification.


• Read the definition on requirements. This definition should give another point of view with regards to my lecture.


• Find the definition of the three relations (composition/containment, refine, deriveReqt), and read them. They shall be a bit different, more generic, because I have defined these relations in the context of embedded systems (so I have made them more explicit).


• List the other relations between requirements I have not presented.

Practising with Requirement Diagrams

Making good models rely mostly on experience. So, you obvisouly need to practise.

1. Open the slides on Exercises


2. Read the specification of the Railroad crossing system


3. Make your own requirement diagram of this system. Try to have between 10 and 15 requirements. You can make your model on paer, or do it with TTool. If you decide to do this with TTool, install TTool first. Once you have started TTool, simply make "new model" and then make a right click on the main panel, and select "New Requirements Diagram", and then again a right-click "new AVATAR Requirement Diagram". Don't forget to regularly save your model (just in case, there is an autosave in a file ending with "~").


4. Auto-correct your diagram. How to do? Simply forget as much as possible about the system specification, and read your requirement diagrams. From this diagram, try to reconstruct the system specification, as if you have never read it before. Then, compare your system specification with the main goals (and anti-goals) of the original specification. Are they similar? Does your diagram contain non relevant requirements? On the contrary, have you forgotten important goals of the initial specification? Auto-correcting your diagram is important because (i) I won't be always available to read your diagrams, (ii) You may have to do this as an engineer in a company.


5. Once you are satisfied with your model, exchange your diagram with the diagram of another student of the course, via email/whatsapp/zoom (avoid exchanging papers). Read and propose improvements on the diagram you will receive, and listen carefully to the suggestions you will receive on your own diagram. Do not say anything about your diagram to the student checking it. Indeed, if you need to give information on your diagram, probably your diagram could be improved.


6. You may also want to have the opinion of your teacher. Do ask by zoom for remarks.


7. Imagine now that I change "Make the requirement diagram of the system (i.e. the software)" by "Make the requirement diagram of the whole systems (including the software)". What would you change in your current requirement diagram? Ideally, clone your diagram and update the cloned version with the requirements for the whole system.