technology for a better society tdt4140 software engineering 29.01.2013: 1 experiences from...

Technology for a better society

TDT4140 Software Engineering 29.01.2013:

1

Experiences from Requirements Engineering:Coping with requirements in large, distributed projects

Guest lecture by Per Håkon Meland ([email protected])

Technology for a better society 2

• Customers know exactly what they want• All developers understand what the customers

want• Everyone knows what to do and when to do it• The customers never change their mind• The budget covers all features (and then some…)• Everything is nice and stable

In an ideal world…


We need Requirements Engineering (RE)!

In our world…


• Type of product• Hardware/software• Simple/complex• Critical/leisure• Novel/standard

• Type of development method• Waterfall/agile• Long-term/rapid• Large team/small team• Cross-organizational/

single organization

4

Choice of RE method?

Courtesy of Tiny Wings


Small projects – keep it simple!

https://sourceforge.net/projects/cloudsurfer/


• Interconnected software services and tools• Collaborative project• 18 organizations• 42 months• ~40 active participants• Budget ~14 M€• DoW/contract: 138 pages

6

Case: (not that simple)

http://www.aniketos.eu/

RE Goals: • Understand• Agree upon• Work guide• Responsibilities


Where did requirements come from in Aniketos?


• Describe visions of behaviour• Purpose: Requirements elicitation• Typically 3-4 requirements per scenario

8

Scenario descriptions (section 4.5.3)


Scenario example


Misuse scenario example


Alternative: Use cases (section 4.5.4)

http://www.shields-project.eu/


http://universaal.org/

12

Alternative: Comic strips


Requirements elicitation and analysis(section 4.5)


Requirements elicitation and analysis(Aniketos)

Identify requirementfrom a scenario or other source

(WP1 Participant)

Requirements handling

Filter and refine requirementRevise Description, add Target

phase and Target WP(Technical manager)

Endorse requirementRevise Description, Target phase

and Target WP(EB)

Identified by Author

PROCESS (responsible) Status of requirement

Analyse requirementRevise Description, Target phase

and Target WP(Target WP Leader)

Filtered by Technical manager

Analysed by Target WP leader

Endorsed by Executive Board

Rejected?(EB)

Fulfilledin Phase X?

(EB)

Rejected

Achieved in Phase X

Not achieved

Yes

Yes

No

NoDeferred post-Aniketos

No

No, Partially fulfilled,

X++


• Start with business requirements/user requirements/high level requirements

• Easy to understand• Technology independent• … but may define technology constraints

16

Requirements specification (section 4.3)


• ReqID: A unique identifier for each requirement • Title: A short title of the requirement (also unique)• Description: A description of the requirement • Type: The requirements types are based on FURPS:

• Functionality - Feature set, Capabilities, Generality, Security• Usability - Human factors, Aesthetics, Consistency, Documentation• Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy,

Mean time to failure• Performance - Speed, Efficiency, Resource consumption, Throughput, Response

time• Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility,

Configurability, Serviceability, Installability, Localizability, Portability• Source: Originating scenario• Target WP: Ownership

Structured natural language (section 4.3.1)


• Target phase: When• Author: Who formulated• Related to: Other requirements that (partly) cover the same things.• Verification method:

• Inspection/review • Runtime testing • Formal proof • User feedback

• Priority: • 1: Must have• 2: Should have• 3: Nice to have

Make sure that the requirements can be verified somehow!

NB: Pri 2 and 3 are usually overlooked


Example requirements

State what the system should do, not how (that's design)


• More specific than business requirements and user requirements

• Often part of the design• Technology dependent, short term, internal

20

System requirements


• SxC-FR3 Support runtime of security contracts {FR2} • SxC-FR3.1 Derive monitoring rules from security contracts {FR2.1}

• SxC-FR3.1.1 Perform an automatic translation of security contracts to monitoring rules. U1-B

• SxC-FR3.1.2 Store the monitoring rules. U1-B • SxC-FR3.2 Update contracts status based on relevant events {FR2.2}

• SxC-FR3.2.1 Update stored values: 1) if new data are available 2) if monitoring rules require an update. U1-C

• SxC-FR3.2.2 Check the monitoring rules. U1-C • SxC-FR3.2.3 Store the used values. U1-C

21

System requirements examples


• Fulfilment status: • Achieved• Rejected – The requirement is considered to be out-of-scope or not suitable for

the project. • Obsolete – The requirement is not considered relevant any more. • Redundant – This requirement is already covered by another one.• Deferred post-Aniketos – We were not able to achieve this requirement in this

project, but still think it is something valuable to do.• How addressed: An explanation on how the requirements have been fulfilled• Target: The document, module or similar that meets the requirement.• Changelog/comments: Written explanations to changes and minor comments (e.g.

relationship to other work packages).

22

Management (section 4.7)


• The system must never fail and be free from bugs.

23

More examplesNot testable

Actually two requirements

Not very realistic


• The system must hash passwords using a salt created with the java.util.Random class.

24

More examplesProbably too much of a solution (how)

Poor solution as well (java.security.SecureRandom)Technology dependent


• The system must be secure.

• The GUI must be user friendly.

• The system should have a short response time.

25

More examplesUnspecific


• The system may log all break-in attempts in a database.

26

More examples

Non-committing


• Upon password verification, the provided password should be compared with the de-hashed password in the database.

• If the network is down, the system administrator must be notified (e.g. by e-mail).

27

More examples Stupid!


• Input validation

• Firewall

• User friendly

28

More examples

IncompleteNo context


• The Aniketos platform should have a developer centre with a download area (to download Aniketos modules/tools/documentation) containing information about requirements and methods of creating Aniketos compliant services.

29

More examples Too long


• Only the data administrator should have full access to the user database

• The support centre should be able to read information about any user

30

More examples Contradicting


• The login procedure should take no more than 5 seconds for an average user.

• The application must implement a two factor authentication procedure.

31

More examplesConflicting: Usability vs

security


• The ticket ordering system should allow the user to purchase tickets.

32

More examples Irrelevant


•

33

More examples

Missing!


• There is no single RE method for all types of projects• Requirements state what the system should do• Used for validation (are we making the right

product) and verification (are we making it right)• Different levels of abstraction• Assume that they will change, track changes

34

Summary

technology for a better society tdt4140 software engineering 29.01.2013: 1 experiences from...

Documents

better society1415 technology

better society15

better society1011alternative

better societyalso

better society67where

better society11http

better society1617reqid

better society2