31 July 2014 Copyright © 2014 Colin Hood Systems Engineering -1- Requirements Engineering: Eliminate and Automate Colin Hood Systems Engineering Evans Business Centre Regents Pavilion 4 Summerhouse Road Moulton Park Northampton NN3 6BJ Great Britain Tel:

31 July 2014

Copyright © 2012 Colin Hood Systems Engineering -3- AutomateEliminate Traceability Requirements Eliminate and Automate

31 July 2014 Copyright © 2012 Colin Hood Systems Engineering -4- AutomateEliminate Traceability Requirements Eliminate Requirements

31 July 2014 System Interface Mech.-Elect. Interface Mechanical Electronics Elect.-SW Interface Scheduling Software Read Write Filter Priority Feasibility Request Customer Requirements Eliminate Requirements The major work in requirements development the stepwise refinement of interfaces.

31 July 2014 Simple Information Model Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Customer Requirements System Requirements System Architecture Sub-System Requirements Sub-System Architecture Sub-System Detailed Design

31 July 2014 Stepwise introduction of design constraints Every level is a mixture of freedom of choice and constraints, some more, and some less Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Customer Requirements System Requirements System Architecture Sub-System Requirements Sub-System Architecture Sub-System Detailed Design

31 July 2014 Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Customer Requirements System Requirements System Architecture Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Customer System Analyst System Architect Sub-System Analyst Sub-System Architect Sub-System Developer Function Owner and Chief Requirements Engineer Unless someone is responsible for satisfying customer requirements, no-one is responsible for satisfying customer requirements Chief Requirements Engineer Function Owner

31 July 2014 Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Customer Requirements System Requirements System Architecture Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Customer System Analyst System Architect Sub-System Analyst Sub-System Architect Sub-System Developer Architectural Team of Experts The architect as leader of a team of experts The major role of the architects is to act as team leader, leading a team of sub-system experts to negotiate and decide together how higher level requirements should be implemented in sub- systems.

31 July 2014 Copyright © 2012 Colin Hood Systems Engineering Ltd -10- AutomateEliminate Traceability Requirements Automate Requirements

31 July 2014 Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Requirements Processes Customer Requirements System Requirements System Architecture Sub-System Requirements Sub-System Architecture Sub-System Detailed Design Elicit Specify Quality Check Release Understand

31 July 2014 Automatically Creating Textual Requirements Diagrams can be used both to document designs, and to document understanding. Here we consider the diagrams used to document understanding. State Transition Diagram

31 July 2014 Automatically Creating Textual Requirements State Transition Table

31 July 2014 Automatically Creating Textual Requirements Generating sentences from frameworks : specifications written by programmers : direct from specification to code, overwhelmed by design detail : direct from specification to code, design detail pre-determined : Using DOORS to create requirements from templates – 2011: Using DOORS to create requirements from templates For User Requirements this is a simplified example based upon ideas from Richard Stevens: The shall [not] be able to, [under ] [, with ] Sentence Templates

31 July 2014 Copyright © 2012 Colin Hood Systems Engineering -15- AutomateEliminate Traceability Requirements Eliminate Traceability

31 July 2014 Eliminate Traceability  One organisation say they do not document for traceability because:  they find that any documentation is less than perfect,  they do not know where the mistakes are, so  they do not know which documentation to trust,  therefore they mistrust all documented dependencies. Could anyone understand your documentation without your help?

31 July 2014 Copyright © 2012 Colin Hood Systems Engineering -17- AutomateEliminate Traceability Requirements Automate Traceability

31 July 2014 Automate Traceability Creating traceability documentation automatically 1.Traceability via Name 2.Traceability via Object 3.Traceability via Reference 4.Traceability via Link Visio DaVinci DOORS Link Object Name Customer Requirements System Requirements System Architecture Software Requirements Software Architecture RequirementsInterfacesStructureSys. Behaviour

31 July 2014 Copyright © 2012 Colin Hood Systems Engineering -19-  Do as little as possible, and as much as necessary. Conclusion

31 July 2014 Copyright © 2012 Colin Hood Systems Engineering -20- Colin Hood Systems Engineering Evans Business Centre Regents Pavilion 4 Summerhouse Road Northampton NN3 6BJ – UK Tel Systems Engineering since 1985 Founding Member of IREB 2006 (International Requirements Engineering Board) Member of INCOSE since 1998

31 July 2014 Reasons to reduce the number of requirements  It takes twice as long to check a requirement as it takes to write it  It takes twice as long to check a link as it does to create it  It takes about as long to create a correct link as it does to write a requirement  So for each requirement, it takes six times more effort than we might at first think  And then we still have to document the attributes…

31 July 2014 Do not blindly follow a process  widely accepted is the belief that we need to re-write requirements at each level. At the architectural levels some believe that requirements need to be derived from the level above in order to allocate from the system to the sub- systems. In some development environments, this is exaggerated to such an extent that even when it is known that a requirement from a higher level is sufficient and acceptable, the requirement is re-written just because people think that the process demands this.  Well, I would like you to print out the above paragraph, tear it into little pieces, and set fire to it.

31 July 2014 Traceability  Traceability is the ability to follow requirements and related information throughout the network of dependencies.  Creating the possibility to follow requirements and related information throughout the network of dependencies:  takes a lot of time  costs money  introduces errors  is necessary