Requirement Engineering Basics Mustafa Savaşcı Scrum Master / Experienced R&D Software Engineer 

Introduction •What is a Requirement ? 3 •Requirements Engineering 4 •Requirements Development Process 5 •Requirements Development Process in Siemens 6 •Characteristics of good requirements 7 •What shall not be in the definition of Requirements 16 

What is a Requirement? A requirement is: 1. A condition or capability needed by a user of the product or system to solve a problem or achieve an objective. 2. A condition or capability that must be met or possessed by a product or product component to satisfy a contract, standard, specification, or other formally imposed documents. 3. A documented representation of a condition or capability as in (1) or (2).[IEEE 610.12-1990]. 

Requirements Engineering “Requirements Engineering involves all lifecycle activities devoted to identification of user requirements, analysis of the requirements to derive additional requirements, documentation of the requirements as a specification, and validation of the documented requirements against user needs, as well as processes that support these activities.” 

Requirements Development Process 

Characteristics of good requirements • Feasible • Corrected=Validated • Unambigious • Testable=Verifiable • Consistent • Complete • Traceable • Concise 

Feasible Feasible or not Feasible? • The product shall be unbreakable. • The bicycle shall be easy to pedal. • The car shall park itself. • The cell phone shall be affordable by anyone. 

Correct = to be Validated Correct or not Correct ? • The car shall fly through traffic. • The bicycle shall have a comfortable seat. • The camera shall be light as a feather. • The ending of the movie shall be surprising to the audience. 

Unambigious Unambiguous or Ambiguous? • The bicycle shall be easy to pedal. • The camera shall have a retail price of less than US$100. • The car shall be capable of being sold in North America and Europe. • The camera shall be available in different colors like red, green, etc. 

Testable=Verifiable Testable or not Testable? • The product shall be unbreakable. • The bicycle shall be easy to pedal. • The product shall never fail. • Changing channels on the TV using the remote control shall take less than 2 seconds. 

Consistent From a car specification: • The steering wheel will be on the left side. • The car must be sold in every EU country. From a control system specification: • Valves shall respond to a change of position command within one second. • All valve controllers shall be capable of moving a valve from fully open to fully closed in at least 5 seconds. From a request for proposal: • The scripting language for adding macros will be Java. • The language chosen for scripting will support pointers. 

Complete Complete or Not Complete? • The car shall be available in the following colors: red, green, etc. • The interrupt software shall support three switch positions. • All user screens shall paint completely in less than two seconds, not including form screens. 

Traceable Traceable or Not Traceable? • The minutes of the meeting recorded each attending stakeholder and each requested feature, but not which stakeholder requested which feature • Features shall be labeled "FEATNNNN", where NNNN is the feature number. requirements derived from the feature shall be labeled "REQNNNN.YYYY" where NNNN is the feature number and YYYY is the derived requirement number. • A real quote from a product manager: “I can’t tell by looking at the requirements database which requirements are currently in the product” 

Concise • REQ1 Sometimes the user will enter Airport Code, which the system will understand, but sometimes the closest city may replace it, so the user does not need to know what the airport code is, and it will still be understood by the system. • REQ1 The system shall identify the airport based on either an Airport Code or a City Name. 

What shall not be in the definition of Requirements • Do not ramble • Not use should,could,might and may. ‘Shall’ used for sentences. • Do not speculate • Do not express possibilities • Vagueness. (‘tall’) • Standalone ‘This’. • Etc usage • Dangerous parantheses and Slash (‘/’) • TBD (to be defined, to be determined or to be decided) • Passive Voice 

Contact M. Mustafa Savaşcı Scrum Master / Experienced R&D Software Engineer Linkedin : https://www.linkedin.com/in/mustafa-savasci/