Dke Software Engineering

Front 1

Good Software (4 Factors)

Back 1

Maintainability

Dependability (Security)

Efficiency

Acceptability

Front 2

Generic Products <----> Customized Products

Back 2

Generic: Stand-alone system, marketed and sold to anyone who wants it (graphic programs, project management tools, software for specific markets such as a dentist appointment program)

Customized: Software commissioned by a specific customer to meet their own needs (embedded control systems, air traffic control software, traffic monitoring systems)

Front 3

Software specification

Software development

Software validation

Software evolution

Back 3

Specification: Customers and engineers define the software that is to be produced and the constraints on its operation.

Development: The software is designed and implemented.

Validation: The software is checked to ensure that it is what the customer requires.

Evolution: The software is modified to reflect changing customer and market requirements.

Front 4

V-Model

Back 4

Front 5

User Requirement

Back 5

Statements, in a natural language plus diagrams, of what services the system is expected to provide to its users and the constraints under which it must operate. Documents must be understandable by all stakeholders.

Front 6

System Requirement

Back 6

More detailed descriptions of the system's functions, services, and operational constraints. The system requirements should define exactly what is to be implemented. Can be part of a contract.

Front 7

Relation User-System Requirements

Back 7

- Each user requirement has to be addressed in system requirements document.

- User requirements can be more open to interpretation, system requirements should be as little ambiguous as possible.

- Often several system requirements correspond to a single user requirement.

- Use numbers to make correspondence clear.

Front 8

Types of non-functional requirements

(3 main areas, 1-2 examples each)

Back 8

Product requirements (usability, dependability, security)

Organizational requirements (environmental, operational)

External requirements (ethical, regulatory, legislative)

Front 9

Product requirements

Back 9

Specify or constrain the behavior of the system.

Examples include performance requirements on how fastthe system must execute and how much memory itrequires, reliability requirements that set out theacceptance failure rate, security requirements, andusability requirements.

Aka "The system shall react to user inputs throughmouse and keyboard in less than 15 seconds."

Front 10

Organizational requirements

Back 10

Broad system requirements derived from policies and procedures in the customer's and developer's organization.

Examples include operational process requirements that define how the system will be sued, development process requirements that specify the programming language, the development, the development environment or process standards to be used, and environmental requirements that specify the operating environment of the system.

Aka "The system shall be entirely implemented in Java v10.2."

Front 11

External requirements

Back 11

Cover all requirements that are derived from factors external to the systems and its development process.

Examples include regulatory requirements that set out what must be done for the system to be approved for use by a regulator, such as a central bank; legislative requirements that must be followed to ensure that the system operates within the law; and ethical requirements that ensure that the system will be acceptable to its users and the general public.

Aka "The system shall implement patient privacy provisions as set out in the standard IEEE.2016.12"

Front 12

Spiral view of the requirements engineering process

Back 12

Front 13

Problems of requirements elicitation

Back 13

- Stakeholders don't know what they really want

- Stakeholders express requirements in their own terms.

- Different stakeholders may have conflicting requirements.

- Organisational and political factors may influence the system requirements.

- Requirements change during the analysis process (new stakeholders may emerge, business environment may change)

Front 14

Use-cases

Back 14

Scenario based technique in UML which identify the actors in an interaction and describe the interaction itself.

A set of use cases should describe all possible interactions with the system.

High-level graphical model supplemented by more detailed tabular description.

Sequence diagrams may be used to add details (showing the sequence of event processing in the system)

Front 15

Sequence diagrams

Back 15

Part of the UML and are used to model the interactions between the actor and the objects within a system.

Shows the sequence of interactions that take place during a particular use case or use case instance.

The objects and actors involved are listed along the top of the diagram.

Interactions between objects are indicated by annotated arrows.

Front 16

State machine models

Back 16

Model the behavior of the system in response to external and internal events.

Show the system's responses to stimuli (often used for modelling real-time systems)

Show system states as nodes and events as arcs between these nodes (event occurs: the system moves from one state to another)

Front 17

Requirements validation techniques

Back 17

- Requirement reviews (systematic manual analysis of the requirements)

- Prototyping (using an executable model of the system to check requirements)

- Test-case generation (developing tests for requirements to check testability)

Front 18

Requirement reviews

Back 18

- Validity: Does it provide the functions needed

- Consistency: Conflicts between requirements?

- Completeness: All required functions included?

- Realism: Can the requirements be implemented given budget and technology?

- Verifiability: Can the requirements be tested?

- Comprehensibility: Is the requirement properly understood?

- Traceability: Is the origin of the requirement clearly stated?

- Adaptability: Can the requirement be changed without a large impact on other requirements?

Front 19

Requirements management

Back 19

The process of managing changing requirements during requirements engineering and system development (new requirements emerge as a system is being developed and after it has gone into use)

Keep track of individual requirements

Maintain links between dependent requirements (you can assess the impact of requirements changes)

Need for a formal process for making change proposals and linking these to system requirements.

Front 20

Functional Requirements

Back 20

–services the system should provide
–how the system should react to particular inputs
–how a system should behave in particular situations
–may state what a system should not do
–>mainly user requirements not always!!!

Front 21

Non–Functional Requirements

Back 21

–constrains on the services
–timing constrain, standards, etc
–can affect the whole system architecture of a system
–often apply to the system as a whole
–Not always clear which system components affects which non–functional requirement

Front 22

Requirements completeness and consistency

Back 22

Complete: they should include descriptions of all facilities required


Consistent: there should be no conflicts or contradictions in the descriptions of the system facilities


Both at the same time is just a dream wink emoticon

Front 23

Make requirements testable

Back 23

–Imprecise requirements are difficult to test
–impressions can be reasons for arguments(court) –> cost money


–Always make testable requirements
–Always make requirements explicit


–non–fun.–req. are often more difficult to identify and test


e.g. Speed, Size, Ease of use, Reliability, Robustness, Portability

Front 24

Requirements and design

Back 24

–In practice requirements and design are inseparable


e.g. The use of a specific architecture to satisfy non–functional requirements may be a domain requirement

Front 25

Sequence diagrams

Back 25

–Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system
–A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance
–Objects and actros involved are listed along the top of the diagram (Interaction indication with arrows)