Introduction to Requirements Analysis and Systems Design

Give Users what They Want

Not only build the software system right

but also build the right software system

Dr L. Sun

Slide 2

Challenges in Build the Right Software Systems

Lack of relevance to the objectives of the project; or the lack of terms

of reference for the project Lack of clarity in the description of a domain Stakeholders and analysts taking certain knowledge for granted and failing to ensure that there is common understanding Ambiguity and/or uncertainty among the users about what they need from a software system
Problem in communication between development teams Conflicts and/or duplication between requirements Requirements expressed in such a way that it is difficult to assess

whether they have been achieved Design of the software solution did not precisely follow the requirements specifications Inconsistent levels of detail No mechanisms to cope with the requirements change and the solutions evolution

Dr L. Sun

Slide 3

Requirements Analysis and Systems Design

Systems thinking
the process of understanding how things influence one another within a whole

dynamic and complex in nature

establishing a view of the system in a holistic manner all the

properties of a system
examining the linkages and interactions between the elements that

compose the entirety of the system

Dr L. Sun

Slide 4

Systems Thinking Issues

Interdependence of objects and their attributes
independent elements can never constitute a system

Holism
emergent properties not possible to detect by analysis should be

possible to define by a holistic approach

Goal seeking
systemic interaction must result in some goal or final state

Inputs and Outputs

in a closed system inputs are determined once and constant in an open system additional inputs are admitted from the environment

Transformation of inputs into outputs

this is the process by which the goals are achieved

Dr L. Sun

Slide 5

Enterprise Architecture Model

Identify holistically the relevant aspects that constitute a business

application
Design the right functions for the right stakeholders to serve the

right purposes

Dr L. Sun

Slide 6

Key Concepts in Enterprise Architecture Model

The product domain, with the concept product that describes the

(information) products or services that an organisation offers to its customers

The organisation domain, describing the business actors

(employees, organisational units) and the roles they may fulfil

The process domain, describing business processes or business

functions consisting of business activities

The information domain, representing the knowledge in an

organisation and the way it is structured

The data domain, in which information is represented in such a

way that it is suitable for automated processing

Dr L. Sun
Slide 7

Key Concepts in Enterprise Architecture Model (cont.)

The application domain, describing software applications that

support the business through application services

The technical infrastructure domain, comprising concepts for,

e.g., hardware platforms and communication infrastructure, needed to support applications

Service an unit of functionality

some entity (an organisation, a software system, a technology

setting) makes available to its environment

some value for certain entities in the environment (e.g. service

users) (information + processing) + value = service

Dr L. Sun
Slide 8

Layered View - Concepts

Capgemini

Dr L. Sun

Slide 9

Service Architecture Hierarchy of Services

Customer

External business service

Business

Business value

Internal business service

External application service Internal application service External technology service Internal technology service

Application

Technology

Technology capability

Dr L. Sun

Slide 10

Business Layer Metamodel

Dr L. Sun

Slide 11

Business Models in Business Layer

Dr L. Sun

Slide 12

Example of a Business Layer Model

Dr L. Sun

Slide 13

Application Layer Metamodel

Dr L. Sun

Slide 14

Collaboration between Layers

The concepts describing software applications
Take the output from the business layer as the requirements

Dr L. Sun

Slide 15

Application Layer Structure Aspect

The structure aspect defines
any application component, including reusable software components

which can be part of one or more applications

application collaboration types of messages (input-output) needing to be passing

between application components

application interface the logical location where the services of a component can be

accessed
behavioural operations, such as event triggers

application-to-application
application-to-business

Dr L. Sun

Slide 16

Application Layer Behaviour Aspect

Behaviour - (x) of application components
external behaviour of application services application services that realise the business services

exposed through application-to-business interface

internal behaviour of application services supporting services that realise the application services exposed through application-to-application interface

Application service
visible unit of functionality of the component(s) provided by one or more components being exposed through well-defined interfaces

being meaningful to the environment

e.g. external services must support the work performed in a

business process of function via an application-to-business interface

Dr L. Sun
Slide 17

Application Layer Behaviour Aspect (cont.)

Application function
representing internal behaviour of a application component that is

required to realise one or more application services

Application interaction
the behaviour of a collaboration of two or more application

components
(x)s handling message passing between application services

(within their corresponding application components) and results returning (x)s are represented by functional workflow that
is driven by the business process from the business layer
is supported by the required infrastructure services from the

technology layer
Dr L. Sun
Slide 18

Example of an Application Layer Model

Dr L. Sun

Slide 19

Technology Layer Metamodel

Dr L. Sun

Slide 20

Example of a Technology Layer Model

Dr L. Sun

Slide 21

Relations between the Layers

Dr L. Sun

Slide 22

Service-Oriented Configuration between Layers

Connecting the concepts from three layers via a case study

Dr L. Sun

Slide 23

Impact Analysis
What is affected by failure of the Sun Blade server?

Dr L. Sun

Slide 24

Application Layer
Focus on Application Layer across Information aspect, Behaviour

aspect and Structure aspect

Support from Business Layer and Technology Layer

end users needs

technical capabilities

Dr L. Sun

Slide 25

Business Applications Development

Analysis

Specification

Implement

IS Project

Design

Testing

Develop

small --- large

straightforward --- complex

Dr L. Sun

Slide 26

What are Roles of Analysis and Design?

Business Domain
described by articulating users viewpoints

analysis
modelling the understanding

Requirements
mapping on to technical viewpoints scope

design

Software systems
transforming into specifications

DB
Dr L. Sun
Slide 27

Systems Analysis and Design

The two important stages in software lifecycle Analysis Is concerned with what is to be done, not how to do it to identify and describe Problem Space underlying business structures information processing gaps what kind information are required, when, where by who what role perform each function and why constraints, norms, consequences Design Is concerned with how to do it within the scope and context to identify and describe Solution Space programme specifications database structure interface design executable norms
Dr L. Sun
Slide 28

Systems Analysis Activities

Scope the system

to Initiate a project
to work with key project stakeholders to formulate and

communicate the business vision

to gather initial requirements to get the project focused early by translating the initial high-

level vision into something realistic

also to identify potential areas of automation and even to aid in

reengineering the underlying business process

Transform business needs to the system requirements to form the business requirements into something

(specifications) that developers can understand

to consolidate the differing messages of various project

stakeholders into a single and consistent vision

to act as a knowledge integrator
Dr L. Sun
Slide 29

Requirements Analysis
Classifications of requirements

R <<requirements>>

R <<functional>>

R
<<non-functional>>

R <<objective>>

R
<<behavioural>>

R
<<algorithmic>>
Dr L. Sun
Slide 30

Classifications of Requirements

Functional requirements - describe what a system does or is expected to do, referring to its functionality
description of the processing that a system will be required

to carry out
details of the inputs into the system from paper forms and

documents, from interactions between people, such as telephone calls, and from other systems
details of the outputs that are expected from the system in

the form of printed documents and reports, screen displays and transfers to other systems
details of data that must be held in the system

Dr L. Sun

Slide 31

Classifications of Requirements (cont.)

Behaviour requirements (user - oriented)
to describe an interaction between users and a system an interaction -- > course <-- use case a course requires information, events, conditions, rules, actions communications between courses unable to express complexity associated with solutions

Algorithmic requirements (solution oriented)

to describe a element of complex behaviour

no interaction from actors required

expressing business rules or policies chosen by organisations Scheduling algorithms for real-time operating systems Solutions to the travelling salesman problem for logistics companies Seat allocation on airline flights and room allocations for hotel chains Complex price and bonus formulae based on periods, volumes, discounts

and other factors

a single course may evaluate many algorithms (business rules), an algorithm may

be used by many courses

Dr L. Sun

Slide 32

Classifications of Requirements (cont.)

Non-functional requirements
to specify the qualitative characteristics of a solution speed of response availability of the solution or specific elements of it meantime between failure and recovery times ease of maintenance and enhancement usability characteristics: interface design standards not influence the functional requirements, but impact on performance

of functionality
Objective requirements
statements of the critical success factors for a project to ensure alignment to the strategy of the organisation normally dependent on functional or non-functional requirements

Dr L. Sun

Slide 33

Change of Requirements
Driving forces for change of requirements
businesses growth organisation changing

market evolving

Challenges and issues

to ensure systems supporting business sustainability to keep the cost low, but effective to identify and prioritise change of requirements aligned with the

objective requirements
to adopt the right methods for analysis and design

to foster adaptability of systems

Dr L. Sun

Slide 34

Object-Oriented Methods

Dr L. Sun

Slide 35

Methods for Analysis and Design

Data-centric
modelling data structure building business rules for manipulating data

Function-centric
transforming business functions into technical functions embedding business rules in the functions identifying data required and modelling data structure

Process-centric
transforming business processes within which the activities are

performed from across business functions componentising the activities as cognitive patterns encapsulating business rules in the patterns Identifying information required and their relevant data items

Object-oriented and structural methods

Dr L. Sun
Slide 36

Techniques for analysis and design

Dr L. Sun

Slide 37

What is Object-Orientation?
OO is a paradigm which combines procedural abstraction and

data abstraction
Procedural abstraction
Procedures (functions) and routines Computational ability in software systems

Data abstraction
Organising data required in the structure and records entity Procedures manipulate entities

The OO paradigm is an approach to an solution of problems in which all computations are performed in the context of objects

Dr L. Sun

Slide 38

Object-Oriented Analysis and Design

Object-orientation is an approach to systems development
Capturing the structure and behaviour of a software system in little

modules that encompass both data and process (interchangeable: operation/method) A little module is knows as object

Object person

Properties Rose Smith, female, 20/10/1980

Behaviour read, walk, teach

States studying, resting, qualified lecturer

shirt

29.00, 151/2, black, stripe, tailored fit, non-iron cotton

shrink, stain, rip

new, pressed, dirty, worn

sale

0018, create, agree, 10 items, negotiate, 50, calculate, 20/08/2010 close Dr L. Sun

verified, invoiced, dispatched, paid, unpaid, cancelled Slide 39

Basic Features of Object-Oriented Approach

Encapsulation
Bundle data and processing of the data together Draw a capsule around related things

Information-hiding
a sturdy capsule is a black box public interface and private

representation
Message
message = {name of an operation and any required arguments} technical term is signature {name of operation, types of its

parameters, type of the object that the operation returns} Sale.CalulateTotalCost(SaleNo, NumberOfUnit, UnitPrice): TotalCost Through the public interface, an object accesses another object by sending it a message

Dr L. Sun

Slide 40

Basic Features of Object-Oriented Approach (cont.)

Classes and objects

class a taxonomy of objects on an abstract level a generic specification for an arbitrary number of objects which

share the same behaviour A class is constituted by the encapsulation of data abstraction as well as procedural abstraction
Naming classes

context-dependence

Object objects specified by a class an instance is able to perform any operation defined by its class

Dr L. Sun

Slide 41

Basic Features of Object-Oriented Approach (cont.)

Inheritance
The ability of one class to define the data structure and behaviour of its

instances (objects) as a superset of the definition of another class(es) Allowing reuse code
Superclass specify its own unique behaviour which can be inherited Subclass inherit behaviour from its superclass but, define its own unique behaviour for the objects

Dr L. Sun

Slide 42

Modelling Requirements
- outcomes of Systems Thinking
Requirements to be represented in models Model abstraction of the artifact

Environment models
Aspects of the real-world environment in which a software system will

operate - working practice, company culture

Domain models
Common elements and structure of software systems in a particular

application area - stakeholders interests and concerns, intended functions

System specification models
Intended properties of a new system - data, functionalities

System design models

Internal structure and components of a new system - a blueprint for its

construction

Dr L. Sun

Slide 43

Summary
Enterprise application architecture guides business applications

(software systems) analysis and design

The fundamental goal is to build the right software systems
Good design (+ software engineering) should produce good systems A good design is one that is easy to understand

Requirements analysis and software systems design leading to

construction
Essential to ensure traceability

Many methods, notations and tools to support design

UML is currently most popular and industry standard

Good practice towards analysis and design fosters reuse

Dr L. Sun

Slide 44