Requirements Engineering & Management

Requirements engineering & management

Tommi Mikkonen Dept. Computer Science University of Helsinki, Helsinki. Finland [email protected]

www.cs.helsinki.fi Schedule

Mon 30.10. Course overview, Mon 20.11. Configuration management practicalities, Product management (TJM) role in software industry. (TJM) Thu 23.11. Visiting lecture: DX200 life Thu 2.11. Product definition, product cycle (Kari Rossi, Nokia) evolution, product lifecycle (TJM) Mon 27.11. Quality in the context of Mon 6.11. Visiting lecture: SW product software products (AP) management in a startup (Juhana Thu 30.11. Software product Peltonen, Hanken) management and testing (AP) Thu 9.11. Visiting lecture: Data Mon 4.12. Visiting lecture: Dependability collection for product management in software products (Francis Tam) (Riku Suomela, NextGames) Thu 7.12. Connecting the dots: Tools and Mon 13.11. Requirements methods for planning, managing, management and engineering tracking, etc. (TJM) (TJM) Mon 11.12. Backup time Thu 16.11. Visiting lecture: Product management in practice (Olli Thu 14.12. Revisit of the course contents Nuutinen, M-Files) (AP?) Schedule

Mon 30.10. Course overview, Mon 20.11. Configuration management practicalities, Product management (TJM) role in software industry. (TJM) Thu 23.11. Visiting lecture: DX200 life Thu 2.11. Product definition, product cycle (Kari Rossi, Nokia) evolution, product lifecycle (TJM) Mon 27.11. Quality in the context of Mon 6.11. Visiting lecture: SW product software products (AP) management in a startup (Juhana Thu 30.11. CANCELLED Peltonen, Hanken) Mon 4.12. Visiting lecture: Dependability Thu 9.11. Visiting lecture: Data in software products (Francis Tam) collection for product management (Riku Suomela, NextGames) Thu 7.12. Connecting the dots: Tools and methods for planning, managing, Mon 13.11. Requirements tracking, etc. (TJM) management and engineering (TJM) Mon 11.12. Software product management and testing (AP) Thu 16.11. Visiting lecture: Product management in practice (Olli Thu 14.12. Revisit of the course contents Nuutinen, M-Files) (AP?) What happens to essays?

Graded with 3 levels: • Pass • Extra tasks to fix the essay • Fail So far all have passed • Will add data to course home page (or moodle, whichevery you prefer)

If you cannot make it to guest lectures, you can write up to 3 essays based on 2-3 research articles • You can search articles by yourself, but check with me that those are ok • Deadline for everything extra is 18.12. (the exam day) Comments regarding “lean startup & design thinking”

The big picture of “Lean Startup”: Iterative approach to seek profitable business model • Feedback loop • Focus on learning; MVP != MVP • Iterations drive towards a goal that is being refined as a part of the process • Non-technical/low-tech prototypes Systematic approach in both • Well-organized • Seemingly independent of who executes the tasks (like research) Comments regarding “data collection and use”

The big picture: Refining product(s) and product ideas based on collecting data Converging series of prototypes/designs leading to more and more data regarding the product; different tools at different stages (user interviews, MVP, A/B testing, data collection from player behavior) KPIs (key performance indicators) play a key role • Profitable business not identified -> pivot to next idea? Requirements engineering & management

Tommi Mikkonen Dept. Computer Science University of Helsinki, Helsinki. Finland [email protected]

www.cs.helsinki.fi “The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult in establishing the detailed technical requirements, including the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the results if done wrong. No other part is more difficult to rectify later. ” - Fred Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering” Content

What is a requirement? Requirements engineering, specification, and management Detailed activities Characteristics of a good requirement For further reading Summary and conclusions What is a requirement?

The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as: 1. A condition or capability needed by a user to solve a problem or achieve an objective. 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. 3. A documented representation of a condition or capability as in 1 or 2. Business goals -ideas, leads, etc. -understanding Business needs & -documentation understanding - ...

Client (or system) Functional Non-functional Limitations, requirements requirements requirements constraints

Software requirements Functional specification Lot of terminological mismatch (e.g. https://en.wikipedia.org/wiki/Requirements_management, https://en.wikipedia.org/wiki/Requirements_engineering)

Requirements management is… Requirements engineering is… process of process of documenting, defining, analyzing, documenting and tracing, maintaining requirements. prioritizing and agreeing on requirements, and then controlling change and communicating to relevant stakeholders. One possible interpretation (that makes sense)

Requirement engineering

Requirement Requirement specification management

Elicitation Analysis Documentation Validation

13 -stakeholder needs (clients, users, marketing, management...) -existing systems -domain specific characteristics -client organization practicalities -regulation -...

-Elicitation Requirements -Analysis for future -Documentation versions -Validation

Accepted Requirements specification requirements Requirements management Accepted changes Changes in Requirement requirements Changes in change the project process Associated key activities

Requirements elicitation • Developers and stakeholders meet, the latter are inquired concerning their needs and wants regarding the software product. Requirements analysis • Requirements are identified (including new ones if the development is iterative) and conflicts with stakeholders are solved. Both written and graphical tools (the latter commonly used in the design phase but some find them helpful at this stage, too) are successfully used as aids. System modeling (sometimes optional) • Some fields (or specific situations) require the product to be completely designed and modeled before its construction or fabrication starts and, therefore, the design phase must be performed in advance. Associated key activities

Requirements validation • Checking that the documented requirements and models are consistent and meet the needs of the stakeholder. Only if the final draft passes the validation process, the RS becomes official. Requirements documentation • Documenting the requirements and their motivations Requirements management • Managing all the activities related to the requirements since inception, supervising as the system is developed and, even until after it is put into use (e. g., changes, extentions, etc.) Client requirement vs. sw requirement

Client requirement – client’s problem waiting for solution: ”producing as correct and error-free User/client/ customer solutions as possible” Req. Feature – a functional entity that is meaningfully defined from client’s perspective jokin asiakkaan Software/ kannalta mielekäs kokonaisuus ohjelmiston technical toiminnallisuudesta: ”support for spell-checking” Req. Function – one operation that the system can perform: ”check spelling”, ”propose fix”, ”automatically fix”, … Technical requirement – how to implement the system: ”file buffer”, ”dialog implementation”, … (notice that this classification is not obvious or unambigiuous)

12.9.2009 Constraints

Constraint 1 Constraint 2

All possible solutions

12.9.2009 Characteristics of a good requirement completeness: includes everything that is needed but nothing useless/extra preciseness correctness understandability testability: how to ”measure” that the requirement is satisfied? traceability: where the requirement originates, how important it is, one thing only in one place (no redundancy) (?)

12.9.2009 Examples

”The system can use a 64kb memory” ”A school can have only one headmaster?” ”Storage cycle speed increases” ”Report must be on screen within 300ms after the alarm has been set” ”Jet engines may not be set to reverse unless the plane is on on the field” ”Jet engines may not be set to reverse unless the front wheel is rolling or the speed is zero”

12.9.2009 How to find client requirements

• Domain knowledge is fundamentally important • Make a list of stakeholders • What hopes, expectations, fears etc. they have • Discuss with users in their daily job context • Plan the visits; play dumb • Ask reassuring questions ”so you mean that…” • Use presentation formats that the client understands • Analyze and document learnings from visits, summarize • Go for the ultimate problem • Why to do something, can it be left undone? • Try to separate essentials from traditional practices • Prototyping, previous versions, related systems • User Centered Desing

12.9.2009 Documenting requirements (example)

Creation date Author Client, origins of the requirement Type of requirement (addition, modification, bug fix) Definition of the requirement Relation to other requirements Ranking (must have, preferable, extra) Stability: will not change, may change, likely to change

12.9.2009 Requirements definition process

Ideas, Requirements definition process Leads, Constraints Limitations Understanding the problem; Specifying Eliciting the system requirements to implement

Customer/client Software/technical requirements Upgrades, requirements bug fixes Functional specification; Draft user manual; Project plan for Inspection implemenation; or review Test plan

OK Client requirements Architectural Become software requirements design Methods, tools, and techniques

Class diagrams, state diagrams, event diagrams, … Method = graphical notation + instructions ”Document-oriented” approach usually overrules methodological considerations Agile methods Requirements are usually defined at a generic level • XP: user story • Scrum: product backlog New versions are constantly created; they act as specifications as well Test-drived development can also regarded as a specification Tools: upper case: modeling and document generating systems lower case: developing software applications

12.9.2009 Iteration between versions

Spesification N Spesification N+1 Constraints and limitations Constraints and limitations

Non-functional requirements Specification Non-functional process requirements Requirements Functional requirements Functional requirements

Verification and validation (e.g. inspections)

12.9.2009 Same time elsewhere….

“The principal perceived problems were incomplete requirements, moving targets, and time boxing, with lesser problems being communications flaws, lack of traceability, terminological problems, and unclear responsibilities” [Fernández, Daniel Méndez, and Wagner, Stefan. "Naming the pain in requirements engineering: A design for a global family of surveys and first results from Germany." Information and Software Technology 57 (2015): 616-643.]. “Problem structuring, a key aspect of requirements engineering, decreases design performance.” [Ralph, Paul, and Mohanani, Rahul. "Is requirements engineering inherently counterproductive?." Proceedings of the Fifth International Workshop on Twin Peaks of Requirements and Architecture. IEEE Press, 2015.] “Requirements are an illusion misrepresenting design decisions as requirements in situations where no real requirements are evident.” [Ralph, Paul. "The illusion of requirements in software development." Requirements Engineering 18.3 (2013): 293-296.] Same time elsewhere….

“For many years, research results in requirements engineering (RE) have been developed without much interaction with, or impact on, industrial practice. Why is it so difficult to introduce RE research results into mainstream RE practice?” [Hermann Kaindl, Sjaak Brinkkemper, Janis A. Bubenko Jr, Barbara Farbey, Sol J. Greenspan, Constance L. Heitmeyer, Julio Cesar Sampaio do Prado Leite, Nancy R. Mead, John Mylopoulos, and Jawed Siddiqi. "Requirements engineering and technology transfer: obstacles, incentives and improvement agenda." Requirements Engineering 7, no. 3 (2002): 113-123.] For further reading

No Silver Bullet: Essence and Accidents of Software Engineering http://www.itu.dk/people/hesj/BSUP/artikler/no-silver-bullit.pdf Naming the pain in requirements engineering

http://www.sciencedirect.com/science/article/pii/S0950584914001256 Is requirements engineering inherently counterproductive?

https://dl.acm.org/citation.cfm?id=2821489 The illusion of requirements in software development https://link.springer.com/article/10.1007/s00766-012-0161-4 Requirements engineering and technology transfer: obstacles, incentives and improvement agenda

https://link.springer.com/article/10.1007/s007660200008 Summary and Conclusions

Understanding the domain is the key to understand user requirements Daily users typically know it best what is the problem to be solved Several formats and notations to document the requirements • Select a one that the end users will understand • If several alternatives, go for one that best supports development activities