System Engineering: from marketing requirements to product specifications

System Engineering: from marketing requirements to product specifications

Larisa Melikhova Dmitry Vavilov

St.Petersburg Software Center

Motorola St.Petersburg Software Center

October 2008

http://panphoto.spb.ru/files/pictures/001/pan_1002.jpg

System Engineering: from marketing requirements to UI specifications April 20, 2023 2

Motorola Document Classification, File Name, Rev Number Add additional legal text here if required by your local Legal Counsel. MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office. All other product or service names are the property of their respective owners. © Motorola, Inc. 2007

Work process as it was

MarketingRequirements(MR)

Test suites

Test cases

Technical Requirements(TR)

Project Functional Specifications(PFS)

Product development Testing



Current work process

MarketingRequirements(MR)

Test suites

Test cases

Technical Requirements(TR)

Project Functional Specifications(PFS)

Product development Testing

User Interface

Mot April 20, 2023


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.



3 Level Model

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.

MR/FR: Marketing level

TR: System level

PFS: Implementation level

2 types: F (functional) and UI; mapped to FRsMature or stable requirements that are unlikely to be changed in the foreseeable future. Invariability and possibility of being tested in a black box model

Describing functions of the device



System engineer’s role

• Specialization: gathering knowledge• Adjustment of experts from all sides:

Marketing <-> User Interface <-> Development• Considering the system as a whole• Focus on User

Analyze System Architecture

Develop & Maintain Requirements

Develop & Maintain Interfaces

AnalyzeDesign

Conduct Technical Reviews

Gather knowledge

PFSPMR



Requirements Guidelines

Clear precise statement

Unambigous

Laconic

Complete

Action expressedOne response to one or more

stimuli



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.



Examples of requirements ratio

EPG

74

46

5

PFS

MRs

TRs

DVR

82

41

8

PFS

MRs

TRs



SE Example: Focus Window

The list of questions for System Engineer to describe the behaviour of STB :

1) During initialization

2) In case of conflicts for resources

3) After recorded show is finished

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)



SE Example: Recording

2 types of recording:

1. Time frame based (DVR)

2. 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



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)



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



Documents

System Engineering: from marketing requirements to product specifications