REQUIREMENTS AND SYSTEM ENGINEERINGWeek 4

OUTLINE

System engineering Requirements elicitation Assignment

WHAT IS SYSTEM ENGINEERING An interdisciplinary approach and means to

enable the realization of successful systems. Focuses on defining customer needs and required

functionality, documenting requirements then proceeding with the design synthesis and system validation while considering the complete problem Operations Performance Test Manufacturing Cost and schedule Training and support Disposal

Consider both the business and technical needs -> providing a quality product that meets the user needs

SYSTEM ENGINEERING PRINCIPLES

INCOSE 1993 Know the problem, know the customer and know

the consumer Use effectiveness criteria based on needs to

make the system decisions Establish and manage requirements Identify and assess alternatives so as to

converge on a solution Verify and validate requirements and solution

performance Maintain the integrity of the system Use an articulated and documented process Manage against a plan

5

Requirements definitions

System design

Sub-system development

systemintegration

Systeminstallation

System evolution

SystemdecommissioningSystem modeling

Concerned withhow the system functionalityis to be providedby the componentsof the system

Implements all sub-system,identified during system design

Specify whatthe system, should doand its desirable system properties

Put sub-systems together to make up a complete system

Change to correct errors in the original system req and to implement new req

Taking the system out of service

Put the system into operational use

WHAT IS SYSTEM Wikipedia - a set of entities, real or abstract,

comprising a whole where each component interacts with or is related to at least one other component and they all serve a common objective. IEEE - a collection of components organized to

accomplish a specific function or set of functions US Air Force - an integrated composite of people,

products, and processes that provide a capability to satisfy a stated need or objective

A set of interrelated components which interact with one another in an organized fashion toward a common purpose (NASA systems engineering handbook)

THE COMPOSITION AND DECOMPOSITION OF COMPLEX SYSTEM

The decomposition continue until a large number of subsystems are developedF22 fighter aircraft – 152 subsystems

WHEN THE JOB IS DONE

Distribution and partitioning of functionality are optimized – overall functionality with minimal costs and maximum flexibility

Each subsystem can be defined, designed and built by a small team

Each subsystem can be manufactured within the physical constraints and technologies of the available manufacturing processes

Each subsystem can be reliably tested as a subsystem

EMERGENT PROPERTIES

Properties of the system AS A WHOLE Not determined solely from the properties of the

system parts but also from the system’s structure

Emergent properties reflect the business requirements

Examples A bicycle has the emergent property of being

a transportation system when the parts are assembled in the right way.

A mobile phone has the emergent property of being a communication device.

EMERGENT NON-FUNCTIONAL PROPERTIES

Important emergent properties of a system are Performance Reliability Safety Security Usability

Some or all of these properties are usually more important than detailed system functionality

THREE PHASES IN SE LIFE CYCLE

Definition (Concept) definition of the requirements for a system

Development (Production) development of the system itself

Deployment (Operation) deployment of the system in an operating

environment Any SE project must do RE. RE process, and

its place in the whole SE process is affected by the process model we follow.

RE IN SE PROCESS MODELS

RE IN INCREMENTAL MODEL

Each release adds more functionality

RE IN RATIONAL UNIFIED PROCESS

OUTLINE

System engineering Requirements elicitation Assignment

REQUIREMENTS ENGINEERING IS MORE OF AN ART THAN A SCIENCE

Metrics Standards Tools Methods Techniques Templates

Training Characteristics Communication Negotiating Language Problem Solving Expectations Assumptions Interpretation Judgement Perception Listening Skills Background Culture

20% 80%

REQUIREMENTS ELICITATION

The process through which to Discover, reveal, articulate, and understand the

problem to be solved, the system services, the required performance of the system, hardware constraints, and so on

Requirements discovery, requirements acquisition

GATHERING INFORMATION FROM … Stakeholders

Interviews and discussions with stakeholders Observing users at work Scenario analysis of user tasks

Documentation Documents that describe current or competing

products Problem reports and enhancement requests for a

current system Marketing surveys and user questionnaires

External sources Other companies, vendors, publications,

seminars, workshops, on-line data services

REQUIREMENTS ELICITATION IS A CHALLENGE ACTIVITY

“Lack of User Input” is the most common factor of failed or challenged projects

People find it hard to describe knowledge they regularly use

Requires collaborations of people with different backgrounds A variety of stakeholders A number of requirements elicitation techniques Analysts should identify a set of appropriate

techniques to elicit requirements proactively

THE REQUIREMENTS ELICITATION PROCESS

Businessgoals

Systemconstraints

Problem to besolved

Establish objectives Understand background

Organisationalstructure

Applicationdomain

Existingsystems

Stakeholderidentification

Goalprioritisation

Domainknowledge

filtering

Organise knowledge

Stakeholderrequirements

Collect requirements

Domainrequirements

Organisationalrequirements

COLLECT REQUIREMENTS FROM MULTIPLEVIEWPOINTS

If the requirements are collected from a single viewpoint, it is unlikely meet other stakeholders requirements

Collecting requirements from multiple viewpoints is a useful way to prioritize requirements

Identified viewpoints can be used to help organize requirements elicitation and organization in the requirements specification

USE BUSINESS CONCERNS TO DRIVEREQUIREMENTS ELICITATION –GOAL ORIENTED APPROACH

If a system is to be useful, it must contribute to the key concerns of the business (business objective). If the concerns are identified and used as drivers of the requirements elicitation process, there will be higher confidence that the system will meet real organization needs

Making the business concerns explicit helps to focus and clarify these goals

REUSE REQUIREMENTS Reuse involves taking the requirements which

have been developed for one system and using them in a different system

Saves time and effort, and reduces risk Studies have shown that similar systems can re-use

up to 80% of the requirements Reused requirements have already been analyzed and

validated in other systems Reused requirements have a better chance of being

understood by all the stakeholders. Requirements reuse may lead to additional reuse

in other lifecycle activities Currently, requirements reuse is an informal

process but more systematic reuse could lead to larger cost savings

ELICITATION TECHNIQUES

Requirements development is an intensive interaction process between stakeholders and analysts

The elicitation techniques can be classified based on the means of interaction Conversational Observational Analytic Synthetic

Conversational methods A means of verbal communication between two

and more people, e.g. interview, workshop, focus groups,

brainstorming, etc. Practical and efficient to collect non-tacit

knowledge Labor intensive, and challenge to facilitate the

elicitation session

Observational methods A means of developing a rich understanding of

the application domain by observing human activities

e.g. observation, ethnographic study, protocol analysis, etc.

Tacit requirements elicitation, understanding complex societies rather than making judgements

Longitudinal studies

Analytic methods A means of exploring the existing documentation

or knowledge and acquire requirements from a series of deductions

e.g. documentation studies, requirements reuse, laddering, card sorting, etc.

A complementary way to deduct and reuse knowledge

Requirements are captured from other sources, e.g. expert knowledge, documents, etc.

Synthetic methods A means of combining conversation, observation,

and analytic techniques into one e.g. scenarios, storyboards, prototyping,

JAD/RAD session, etc. Good cues for requirements recognition Harmonize the requirements stage with other

stages

PERSPECTIVES OF METHODS SELECTION Requirements abstraction level

Generic problem analysis Specific product description

Requirements source Human being Other environments

•Communication obstacles National culture Organizational culture Individual cognitive limitation across time and space

Requirements certainty Well-structured problem domain Unstructured problem domain

OUTLINE

System engineering Requirements elicitation Assignment

ASSIGNMENT

Plagiarism issue Turnitin software

E-mail for registration purpose

BUSINESS MODELING

Purpose To understand the structure and dynamics of the

existing organization To ensure that customers, end users and

developers have a common understanding of the organization

To understand how to deploy new systems to facilitate productivity and which existing systems may be affected by that new system

USING SE TECHNIQUE

UML – graphical language for visualizing, specifying, constructing and documenting the artifacts of software systems

Business use case model Meet with customer to negotiate contract terms Actors : customer, employee, software

developers

Business object model Describes the entities and how they interact to

deliver the functionality necessary to realize the business use case

Businmess

FROM BUSINESS MODEL TO SYSTEM MODEL

Business use case model

Business object model

System modeling

Use case modelDesign model

Actor-circle icon – actor within the business process

Business entity or something workers produce

Business level