Requirements Engineering I

Assignment 1 – Solution & Discussion

Irina Todoran Rita Forster

October 14th, 2013

Overview

•  Assignment generally well solved

•  Attention to details: very important

•  Numerous tasks only partially solved

•  Assumptions need to be documented

•  Vague specifications and needs provided by stakeholders: natural in everyday life

2

2.1 Requirements Engineering Activities

●  Describing the activities: what is important and what can be left out

●  Quality attribute: a property of a process or product that can have some qualitative or quantitative value, and can be measured or observed. ü  Examples: adequacy, completeness, verifiability etc.

3

2.1 Requirements Engineering Activities

4

2.1 Requirements Engineering Activities

Requirements elicitation: the process of seeking, capturing and consolidating requirements from available sources. • Stakeholder analysis • Document analysis • Context analysis • Analysis of existing systems • Observation à Initial list of requirements and stakeholders

5

2.1 Requirements Engineering Activities

Requirements analysis: determining whether the stated requirements are clear, complete, consistent and unambiguous, and resolving any apparent conflicts.

• Ordering of requirements • Introducing a glossary • Searching for mistakes in the requirements • Resolving possible conflicts • Prioritisation of requirements • Building models • Analysing technical feasibility

à Prioritised, consistent list of requirements 6

2.1 Requirements Engineering Activities

Requirements documentation: written manifestation for increased understanding.

• Structuring of requirements • Tools: - Natural language - Structural and interaction models - Formal models - Specification templates

à Draft requirements document

7

2.1 Requirements Engineering Activities

Requirements validation: checking the requirements for validity, consistency, completeness, realism and verifiability.

• Validation of content • Validation of documentation • Validation of agreement

à Requirements document and validation report

8

2.1 Requirements Engineering Activities

Quality attribute matrix

9

These(four(steps(are(performed(one(after(another.(After(the(validation( it(must(be(decided( if(the(document(can(be(accepted(as( it( is(or( it(must(be(extended.(In(the(latter(case,(it(will(be(started(with(the(first(phase(again.(

$ Elicitation$ Analysis$ Documentation$ Validation$Adequacy$ ( x( x( x$

Completeness$ ( ( ( x$Consistent$ ( x( x( x$

Understandable$ ( ( x( x$Unambiguous$ ( x( x( x$Verifiable$ ( x( x( x$

Insuring$minimal$risk$ ( x( x( x$Accepted$ ( ( ( x$Prioritized$ ( x( ( x$Correct$ ( ( ( x$

Realisable$ ( x( ( x$Traceable$ x( x( x( X$

(

(

2.1 Requirements Engineering Activities

Comments:

•  Numerous submissions are missing the quality attributes and explanations

•  Read the tasks carefully!

Grading:

1p * activity description => 4p 0.5p * quality attribute => 4p 0.5p * explanation/activity => 2p Total: 10p

10

2.2 Stakeholders Identification (1)

11

Contact�person� Why�important� Expected�information�National�Council� Client.� Functional,� performance� and� specific� quality�

requirements,� constraints.� Information� about�stakeholders�involved.�

Mayor�of�Futurecity� Pilot�partner.� Requirements� for� the� interface,� information� about�current�solution.�

University�of�Futurecity� Commissioning� legal� and�socioͲpolitical�studies.�

Legal,�cultural�and�social�constraints.�

Private�companies� Developing,� performing�testing.�

Interface�and�project�constraints.�

Voters� End�users.� Suggestions� for� usability,� security,� availability,�reliability,�speed.�

The�Futurlanders�abroad� ͲͲͲ“ͲͲͲ� ͲͲͲ“ͲͲͲ�Futurecity�police� Responsible� for� physical�

access�to�the�system�servers.�Legal,�organizational�and�physical�restrictions.�

Political�parties’�controllers� Needed� for� opening� the� eͲballot�box� and� generating� all�the�results.��

Legal� and� organizational� restrictions,� functional�requirements.�

Software�developers�of�my�company�

They�realize�the�project.� Feasibility�analysis.�

National�Office�of�Statistics� Receive�a�file�for�statistics.� Functional� requirements� to� the� format� and� the�content�of�the�file.�

�

� �

2.2 Stakeholders Identification (1)

Comments:

•  Two few stakeholders detected

•  What requirements do you expect to elicit? – Ignored

•  Could you profit from legal and socio-political studies?

•  Expecting the necessary data to be delivered without elicitation effort, eg. this info is provided by entity X

12

2.2 Elicitation Techniques (2)

Comments:

• Background Reading • System Archaeology • Observation • Interviews • Surveys • Workshops • Prototypes • Use Cases

à What would you like to find out? à Why is the selected method better than others?

13

2.2 Stakeholders Identification and Elicitation Techniques Grading:

1) 1p * stakeholder => 7p 0.25p * reason(s) why important 0.25p * type of info expected 0.25p * importance assessment

0.25p * argumentation for the classification

2) 1p * technique => 3p 0.5p * name of a suitable technique 0.5p * how to implement it in practice

Total: 10p

14

2.3 Context Diagram

15

Requirements Engineering I Assignment 1 Fabian Christoffel, s05-729-686!

September 30, 2013 3

National Council responsible for the voting process: Build, explore and discuss prototypes and mock-ups The national council responsible for the voting process seems to have a vague idea of the functional and non-functional capabilities and the appearance of the system. To make sure that we really match these expectations we present the latest prototypes and mock ups to project responsible persons of the council on a regular basis to get to know what should be changed / improved from their perspective. To make sure we really grasp the needs of our sponsor it would be probably best if the current work artifacts are presented in the of course of a series of workshops based on successively more detailed specifications. Citizens / voters: questionnaires and polls We conduct telephone polls with a representative group and a fixed set of question and answers of voters to learn about the expected features of the system to develop and citizens major concerns. Furthermore we will try to get to know some of the shortcomings of the legacy system and reasons why it is not used by more voters. I propose to contact citizens directly by phone to make sure that we get feedback from all social groups and not only from the people already familiar wit the e-voting system. The poll could be enriched with open answers to interview questions. Citizens / voters: Observe stakeholders in their work context It seems like nobody really knows the reason why the legacy system was not accepted by the citizens as a new easy way for voting. Therefore we should conduct experiments with a representative group of citizens: We simply observe them while they are using the legacy system in a test ballot to see what the main shortcomings in terms of usability of the legacy system are. Subsequently to the experiment we can interview the test candidates to verify our observations. Task 2.3 Context Diagram

Task 2.4 Specification process 1.

• Criteria to consider when designing a RE process: • Accessibility of stakeholders / size of feedback cycle • Identifiability of stakeholders • How good is our domain knowledge? • What degree of detail is needed in the specification? / What is the tolerable risk? • Do we have fixed deadlines? • Is budget based fixed on deliverables or does it adapt to workload? • Are we the only supplier or are other organizations involved in project? • Can we deliver multiple releases? • Do we have to make assumptions about what stakeholders really expect?

[Fabian Christoffel]

2.3 Context Diagram

16

Another example:

2.3 Context Diagram

The context diagram defines the boundary between the system, or part of a system, and its environment, showing the entities that interact with it

• label your arrows and entities • not all stakeholders must be present

Entities to be included: political parties’ controllers, National Office of Statistics, results management system, registers by municipalities, voters, ...

17

2.3 Context Diagram

18

Grading:

1p * entity => 5p 1p * relation => 5p (incl. double)

Total: 10p For incorrect entities and relations, lack of explanations for assumptions, etc. -1p

2.4 Specification Process

Selection criteria

1) Based on the stakeholder • For a customer or for a market? • Availability of stakeholders in project

2) Based on requirements • Volatility of the requirements • Are the requirements clear in the beginning of the project

19

2.4 Specification Process

Selection criteria

3) Based on project phases • Does the requirements serve as a contractual basis? • Linear or incremental process? • Project duration • Complexity • COTS, self-development, or development through 3rd party? • Is the project critical? • Use of existing or emerging technologies • Existing corporate culture • What has priority: time, costs or functionality? 20

�

� Nr.� Linear� Incremental� Prescriptive� Explorative� COTSͲdriven� Customer�Ͳspecific�

Market�Ͳoriented�

Contractual� 3,5� X� � x� � � x� �Participatory� 8� � x� � X� � X� �ProductͲoriented�� 0,5� � X� � X� � � X�COTS�aware� 0� x� X� � � x� X� �

�

�

�

�

2.4 Specification Process

Selection criteria

Grading:

1) 1p * criteria => 5p (min. 5 criteria) 2) 1p * process => 3p 3) 1p * appropriate process 1p * explanation

Total: 10p

21

?

0

xkcd.com