System Engineering: from marketing requirements to product specifications

1. System Engineering: from marketing requirements to product specifications Larisa Melikhova Dmitry Vavilov St.Petersburg Software Center Motorola St.Petersburg Software Center October 2008

2. Work process as it was • Product development • Testing • Marketing • Requirements • (MR) Technical Requirements (TR) Test suites Test cases Project Functional Specifications (PFS) System Engineering: from marketing requirements to UI specifications October 4, 2014

3. Current work process • Product development • Testing • User Interface • Marketing • Requirements • (MR) Technical Requirements (TR) Test suites Project Functional Specifications (PFS) Test cases System Engineering: from marketing requirements to UI specifications October 4, 2014

4. Three views to be taken into account • The view of the stakeholders whose job it is to specify the requirements (may include customers, consumers, management, etc.) • The view of the development team whose responsibility it is to provide the product that is described by the requirements. • The view of the tester who must verify consistency between the stated intention of the stakeholders and the interpretation of the developer in the form of a product. Mot 10/4/2014

5. 3 Level Model MR/FR: Marketing level Describing functions of the device • Mapped to UI TRs • Requirements that are likely to vary from model to model. • Include details that may relate to the product performance, power consumption, timing parameters, and so on. TR: System level • 2 types: F (functional) and UI; mapped to FRs • Mature or stable requirements that are unlikely to be changed in the foreseeable future. Invariability and possibility of being tested in a black box model PFS: Implementation level System Engineering: from marketing requirements to UI specifications October 4, 2014

6. System engineer’s role Gather knowledge Develop & Maintain Requirements • Specialization: gathering knowledge • Adjustment of experts from all sides: Marketing <-> User Interface <-> Development • Considering the system as a whole • Focus on User PFS PMR Conduct Technical Reviews Analyze Design Develop & Maintain Interfaces Analyze System Architecture System Engineering: from marketing requirements to UI specifications October 4, 2014

7. Requirements Guidelines Clear precise statement Unambigous Laconic Complete Action expressed One response to one or more stimuli System Engineering: from marketing requirements to UI specifications October 4, 2014

8. Achieving Reuse Goals • “Bricks” approach to reusability • Each requirement is considered as a "brick" – an atomic element without product or model-specific terms, not connected with other elements. • Removing specific details • Requirements atomicity • No references to other requirements • Clear and consistent structure • Related requirements grouped together. • Each group preceded by a precise and laconic heading. • Specifications, assumptions & constraints associated with each group. • Unique terminology within the grouping. • Duplications and contradictions removed. System Engineering: from marketing requirements to UI specifications October 4, 2014

9. Examples of requirements ratio System Engineering: from marketing requirements to UI specifications October 4, 2014

10. SE Example: Focus Window In case of development of EPG for STB with two tuners we show some program all the time (in full screen mode or in scaled video area) • The list of questions for System Engineer to describe the behaviour of STB : • During initialization • In case of conflicts for resources • After recorded show is finished System Engineering: from marketing requirements to UI specifications October 4, 2014

11. SE Example: Recording • 2 types of recording: • Time frame based (DVR) • Event based (Guide) • Questions to be answered by System Engineer: • How to display in the Guide • Gathering and storing metadata (genre, actors, etc) • Stop/cancel the recording • Include time shift buffer for recording • Conflict resolution System Engineering: from marketing requirements to UI specifications October 4, 2014

12. Conclusions • System Engineer is an essential participant of software development process who coordinates and integrates the efforts of other players for success of the entire project. • Advantages of separating the sys eng group: • Better coordination of SW development process • View to the entire system • Economy of resources (due to requirements reuse and accumulated expertise) System Engineering: from marketing requirements to UI specifications October 4, 2014

13. References • Larisa Melikhova, Albert Elcock, Andrey A. Dovzhikov, Georgii Bulatov, Dmitry O. Vavilov, " Reengineering for System Requirements Reuse: Methodology and Use-Case", Proceedings of the 11th Annual IEEE International Symposium on Computer Electronics (ISCE 2007), 20-23 June 2007. • Jansma, P.A.; Derro, M.E. If You Want Good Systems Engineers, Sometimes You Have To Grow Your Own! Aerospace Conference, 2007 IEEE. 3-10 March 2007 • A.P. Sage. Systems Engineering of Computer Based Systems: status and future perspectives. Proceedings of the 1995 International Symposium and Workshop on Systems Engineering of Computer Based Systems. 1995 System Engineering: from marketing requirements to UI specifications October 4, 2014

14. Thank you! System Engineering: from marketing requirements to UI specifications October 4, 2014