UKF COLLEGE OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CST 309 MANAGEMENT OF SOFTWARE SYSTEMS
MODULE 2
Requirement Analysis and Design
SYLLABUS
Functional and non-functional requirements, Requirements engineering processes. Requirements
elicitation, Requirements validation, Requirements change, Traceability Matrix. Developing use cases,
Software Requirements Specification Template, Personas, Scenarios, User stories, Feature identification.
Design concepts - Design within the context of software engineering, Design Process, Design concepts,
Design Model. Architectural Design - Software Architecture, Architectural Styles, Architectural
considerations, Architectural Design Component level design - What is a component?, Designing Class-
Based Components, Conducting Component level design, Component level design for web-apps.
Template of a Design Document as per “IEEE Std 1016-2009 IEEE Standard for Information Technology
Systems Design Software Design Descriptions”. Case study: The Ariane 5 launcher failure.

REQUIREMENTS

• These are statements of services

• the system should provide,
• how the system should react to particular inputs
• how the system should behave in particular situations.
• The functional requirements may also state what the system should not do.
• Four types of requirement
• Functional requirements
• Non Functional requirements
• User requirements
• System requirements

FUNCTIONAL REQUIREMENTS

• It describes functionality or services of the system

• i.e. what the user requires from the system.
• These requirements depend on
• the type of software being developed
• the expected users of the software
• the general approach taken by the organization when writing requirements
• Functional requirements should describe the system services in detail.
• Imprecision in the requirements specification can lead to disputes between customers and software
developers.
• New requirements have to be established and changes made to the system.
 • This delays system delivery and increases costs
• Functional requirements specification of a system should be both complete and consistent.
• Completeness means that all services and information required by the user should be defined.
• Consistency means that requirements should not be contradictory.

Examples of functional requirements for the Mentcare system

1. A user shall be able to search the appointments lists for all clinics.
2. The system shall generate each day, for each clinic, a list of patients who are expected to attend
appointments that day.
3. Each staff member using the system shall be uniquely identified by his or her eight-digit employee
number.

NON-FUNCTIONAL REQUIREMENTS

❖ These are constraints on the services or functions offered by the system.

❖ They include timing constraints, constraints on development, and constraints imposed by standards.
❖ Non-functional requirements may be more critical than functional requirements.
❖ Failing to meet a non-functional requirement can mean that the whole system is unusable.

Classification

• Product requirements: Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
• Organizational requirements: Requirements which are a consequence of organizational policies
and procedures e.g. process standards used, implementation requirements, etc.
• External requirements: Requirements which arise from factors which are external to the system
and its development process e.g. interoperability requirements, legislative requirements, etc.

REQUIREMENTS ENGINEERING PROCESSES

There are a number of generic activities common to all processes

I. Requirements elicitation
II. Requirements specification
III. Requirements validation;
IV. Requirements management.

• The output of the RE process is a system requirements document.

 I. REQUIREMENTS ELICITATION

 Sometimes called requirements elicitation or requirements discovery.

 May involve end-users, managers, engineers, domain experts, trade unions, etc. These are called
stakeholders.
 Software engineers work with a range of system stakeholders to
• find out about the application domain,
• the services that the system should provide,
• the required system performance,
• hardware constraints,
• other systems, etc.

Requirements elicitation process

• Requirements discovery: Interacting with stakeholders to discover their requirements.
• Classification and organization: Groups related requirements and organises them into clusters
• Prioritization and negotiation: Prioritizing requirements and resolving requirements conflicts.
• Requirements documentation: Requirements are documented.
PROBLEMS OF REQUIREMENT ELICITATION
• 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.
• The requirements change during the analysis process.
• New stakeholders may emerge and the business environment may change.
Techniques
1. Interviewing
2. Ethnography
1. Interviewing

• Formal or informal interviews with system stakeholders are part of most requirements engineering
processes.
• In these interviews, the requirements engineering team puts questions to stakeholders about the
system that they currently use and the system to be developed.
• Requirements are derived from the answers to these questions.

Interviews may be of two types:

• Closed interviews
• Open interviews
• Open interviews : in which there is no predefined agenda, where various issues are explored with
stakeholders
• Closed interviews :
• stakeholders answers based on pre-determined list of questions
• Give list of questions to stakeholders
• Stakeholder answer those questions
• Based on the answers developers predict the requirements.
2. Ethnography

• A social scientist spends a considerable time observing and analyzing how people actually work.
• People do not have to explain their work.
• Social and organizational factors of importance may be observed.
• Ethnographic studies have shown that work is usually richer and more complex than suggested by
simple system models.
• Requirements are derived from cooperation and awareness of other people’s activities.
• Ethnography is effective for understanding existing processes but cannot identify new features.
• Social scientist stays with stakeholders and analyzes how the work is done manually, what is the
objective of the work, what is the requirement.
• After analyzing the work it is discussed with the entire software development team.
 II. REQUIREMENTS SPECIFICATION

• The process of writing the user and system requirements in a requirements document.
• User requirements have to be understandable by end-users and customers who do not have a
technical background.
• System requirements are more detailed requirements and may include more technical
information.

Notation Description
Natural language The requirements are written using numbered sentences
Each sentence should express one requirement.
Structured natural language Requirements are written in natural language on a standard form/template.
Each field provides information about an aspect of the requirement.
Design description languages This approach uses a language like a programming language
Graphical notations Graphical models, supplemented by text annotations, are used
UML use case and sequence diagrams are commonly used.
Mathematical specifications These notations are based on mathematical concepts such as
finite-state machines or sets.

Guidelines for writing requirements

• Invent a standard format and use it for all requirements.
• Use language in a consistent way.
• Use shall for mandatory requirements, should for desirable requirements.
• Use text highlighting to identify key parts of the requirement.
• Avoid the use of computer jargon.
• Include an explanation of why a requirement is necessary.

III. REQUIREMENTS VALIDATION

• Checks whether the requirements define the system that the customer really wants.
• Requirements error costs are high so validation is very important.
• Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an
implementation error.

Requirement checking

• Validity. Does the system provide the functions which best support the customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer included?
 • Realism. Can the requirements be implemented given available budget and technology ?
• Verifiability. Can the requirements be checked?

Requirement validation techniques

1. Requirements reviews
• Systematic manual analysis of the requirements.
• Requirements are analyzed systematically by a team of reviewers who check for errors and
inconsistencies.
2. Prototyping
• Using an executable model of the system to check requirements.
3. Test-case generation
• Developing tests for requirements to check testability.

IV. REQUIREMENTS CHANGE

• The business and technical environment of the system always changes after installation.
• The people who pay for a system and the users of that system are rarely the same people.
• Large systems usually have a diverse user community, with many users having different
requirements and priorities that may be conflicting or contradictory.

TRACEABILITY MATRIX

• A table type document i.e. used in the development of software application to trace requirements.
• It can be used for both forward (from Requirements to Design or Coding) and backward (from
Coding to Requirements) tracing.
• It is also known as Requirement Traceability Matrix (RTM) or Cross Reference Matrix (CRM).
• It is prepared before the test execution process to ensure that every requirement is covered in the
form of a Test case so that we don't miss out any testing.
• We map all the requirements and corresponding test cases to ensure that we have written all the
test cases for each condition.
The traceability matrix can be classified into three different types which are as follows:

1.Forward traceability
2.Backward or reverse traceability
3.Bi-directional traceability

Goals of Traceability Matrix:

• It helps in tracing the documents that are developed during various phases of SDLC.
• It ensures that the software completely meets the customer's requirements.
• It helps in detecting the root cause of any bug.
Advantages of RTM:

• Display the complete test execution and bugs status based on requirements.
• It is used to show the missing requirements or conflicts in documents.
• We can ensure the complete test coverage, which means all the modules are tested.
• Consider the efforts of the testing teamwork towards reworking

DEVELOPING USE CASES

• The first step in writing a use case is to define the set of “actors” that will be involved in the story.
• Actors are the different people (or devices) that use the system or product
• Actors represent the roles that people (or devices) play as the system operates.
• An actor is anything that communicates with the system or product and that is external to the
system itself.
• Every actor has one or more goals when using the system
• Primary actors interact to
 achieve required system function
 derive the intended benefit from the system.
 They work directly and frequently with the software.
Secondary actors support the system so that primary actors can do their work.

 Once actors have been identified, use cases can be developed.

Jacobson suggests a number of questions that should be answered by a use case:

 Who is the primary actor, the secondary actor(s)?
 What are the actor’s goals?
 What preconditions should exist before the story begins?
 What main tasks or functions are performed by the actor?
 What exceptions might be considered as the story is described?
 What variations in the actor’s interaction are possible?
 What system information will the actor acquire, produce, or change?
 Will the actor have to inform the system about changes in the external environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?

PERSONAS, SCENARIOS, USER STORIES, FEATURE IDENTIFICATION

PERSONAS

• Personas are ‘imagined users’ where you create a character portrait of a type of user that you think
might use your product.
• Eg: if your product is aimed at managing appointments for dentists - create a dentist persona, a
receptionist persona and a patient persona.
 • Personas of different types of user help you imagine what these users may want to do with your
software and how it might be used.
• They help you find difficulties that they might have in understanding and using product
features.
• A persona should ‘paint a picture’ of a type of product user.
• They should be relatively short and easy-to read.

Aspects of Persona Description

1. Personalization
 You should give them a name and say something about their personal circumstances.
 You shouldn’t think of a persona as a role but as an individual.
 Use an appropriate stock photograph to represent the person in the persona.
 Some studies suggest that this helps project teams use personas more effectively.
2. Job-related
 If your product is targeted at business, you should say something about their job
 For some jobs, such as a teacher where readers are likely to be familiar with the job, this
may not be necessary.
3. Education - You should describe their educational background and their level of technical
skills and experience.
4. Relevance - If you can, you should say why they might be interested in using the product and what
they might want to do with it.

Persona Benefits

• Identify the potential users of the software.

• Tool that allows developers to ‘step into the user’s shoes’.
• Instead of thinking about what you would do in a particular situation, you can imagine how a
persona would behave and react.
• Personas can help you check your ideas to make sure that you are not including product features
that aren’t really needed.
 • Avoid making unwarranted assumptions, based on your own knowledge, and designing an
over-complicated or irrelevant product.

SCENARIOS

• A scenario is a narrative that describes how a user, or a group of users, might use your system.
• There is no need to include everything in a scenario – the scenario isn’t a system specification.
• It is simply a description of a situation where a user is using your product’s features to do
something that they want to do.
• Scenario descriptions may vary in length from two to three paragraphs up to a page of text.

• A brief statement of the overall objective.

• References to the personas involved so that you can get information about the capabilities and
motivation of that user.

Writing Scenarios

• Scenarios should always be written from the user’s perspective and based on identified personas
or real users.
• Your starting point for scenario writing should be the personas that you have created.
• You should normally try to imagine several scenarios from each persona.
• Ideally, scenarios should be general and should not include implementation information.
• It is important to ensure that you have coverage of all of the potential user roles when describing
a system.

USER STORIES

• User stories are finer-grain narratives that set out in a more detailed and structured way a single
thing that a user wants from a software system.
• An important use of user stories is in planning.
• Many users of the Scrum method represent the product backlog as a set of user stories.
• User stories should focus on a clearly defined system feature
• If the story is about a more complex feature that might take several sprints to implement
• Then it is called an epic.

FEATURE IDENTIFICATION
• Your aim in the initial stage of product design should be to create a list of features that define
your product.
• A feature is a way of allowing users to access and use your product’s functionality
• So the feature list defines the overall functionality of the system.
• Features should be independent, coherent and relevant:
• Independence - Features should not depend on how other system features are implemented and
should not be affected by the order of activation of other features.
• Coherence - Features should be linked to a single item of functionality. They should not do more
than one thing and they should never have side-effects.
• Relevance - Features should reflect the way that users normally carry out some task. They
should not provide obscure functionality that is hardly ever required.

• User knowledge - You can use user scenarios and user stories to inform the team of what users
want and how they might use it the software features.
• Product knowledge - You may have experience of existing products or decide to research what
these products do as part of your development process. Sometimes, your features have to
replicate existing features in these products because they provide fundamental functionality that
is always required.
• Domain knowledge - This is knowledge of the domain or work area(e.g. finance, event booking)
that your product aims to support. By understanding the domain, you can think of new
innovative ways of helping users do what they want to do.
• Technology knowledge - New products often emerge to take advantage of technological
developments since their competitors were launched. If you understand the latest technology,
you can design features to make use of it.

DESIGN WITHIN THE CONTEXT OF SOFTWARE ENGINEERING

1. Data/Class Design
 Transforms class models into design class realizations and the requisite data structures
required to implement the software.
 The objects and relationships provide the basis for the data design activity.

2. Architectural Design
 Defines the relationship between
 major structural elements of the software
 Architectural styles & patterns that are used to achieve the requirements
 the constraints that affect the way in which architecture can be
implemented.

3. Interface Design
 Describes how the software communicates with systems that interoperate with it, and
with humans who use it.
 An interface implies a flow of information (e.g., data and/or control)

4. Component-Level Design
 Transforms structural elements of the software architecture into a procedural description of
software components.
 Information obtained from the class-based models and behavioral models serve as the basis
for component design.

DESIGN PROCESS

• Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software.
• Initially, the blueprint depicts a view of software.
• That is, the design is represented at a high level of abstraction—a level that can be directly traced
to the specific system objective and more detailed data, functional, and behavioral
requirements.
 • As design iterations occur, subsequent refinement leads to design representations at much lower
levels of abstraction.
• These can still be traced to requirements, but the connection is more subtle.

DESIGN CONCEPTS

1. Abstraction (Hide Irrelevant data):

 Abstraction simply means to hide the details to reduce complexity and increase
efficiency or quality.
 Different levels of Abstraction are necessary and must be applied at each stage
 So that any error that is present can be removed to increase the efficiency

2. Modularity (subdivide the system)

 Modularity simply means dividing the system or project into smaller parts
 To reduce the complexity of the system or project.
 Modularity in design means subdividing a system into smaller parts so that
these parts can be created independently
 Then use these parts in different systems to perform different functions.
 It is necessary to divide the software into components known as modules

3. Architecture (design a structure of something)

 Architecture simply means a technique to design a structure of something.
 Architecture in designing software is a concept that focuses on various elements
and the data of the structure.
 These components interact with each other

4. Refinement (removes impurities)

 Refinement means to refine something to remove any impurities if present and
increase the quality.
 Refinement is very necessary to find out any error if present and then to reduce it.

5. Pattern (a Repeated form)

 A pattern simply means a repeated form or design in which the same shape is
repeated several times to form a pattern.
 The pattern in the design process means the repetition of a solution to a common
problem

6. Information Hiding (Hide the Information)

 Information hiding simply means to hide the information so that it cannot be
accessed by an unwanted party.
  In software design, information hiding is achieved by designing the modules in a
manner that the information gathered or contained in one module is hidden and
can’t be accessed by any other modules.

7. Refactoring (Reconstruct something)

 Refactoring simply means reconstructing something in such a way that it does not
affect the behavior of any other features.
 Refactoring in software design means reconstructing the design to reduce
complexity and simplify it

8. Separation of Concerns:
 Separation of concerns is a design concept that suggests that any complex problem
can be more easily handled if it is subdivided into pieces that can each be solved
and/or optimized independently.
 By separating concerns into smaller, and therefore more manageable pieces, a
problem takes less effort and time to solve.

DESIGN MODEL

• The design model can be viewed in two different dimensions.

• The process dimension indicates the evolution of the design model as design tasks are executed
• The abstraction dimension represents the level of detail as each element of the analysis model
is transformed into a design equivalent and then refined iteratively
• The dashed line indicates the boundary between the analysis and design models.
• In some cases, a clear distinction between the analysis and design models is possible.
• In other cases, the analysis model slowly blends into the design and a clear distinction is less
obvious.
1. Architectural Design Elements
 The architectural design for software is the equivalent to the floor plan of a house.
 The architectural model is derived from three sources:
(1) information about the application domain for the software to be built;
(2) specific requirements model elements such as use cases or analysis classes
(3) the availability of architectural styles

2. Interface Design Elements

 The interface design for software is analogous to a set of detailed drawings (and
specifications) for the doors, windows, and external utilities of a house.
 The interface design elements for software depict information flows into and out of a
system and how it is communicated among the components
 There are three important elements of interface design:
(1) the user interface (UI),
(2) external interfaces to other systems
(3) internal interfaces between various design components.

3. Component-Level Design Elements

 The component-level design for software is the equivalent to a set of detailed drawings
(and specifications) for each room in a house.
 The component-level design for software fully describes the internal detail of each
software component.
 To accomplish this, the component-level design defines data structures for all local data
objects and algorithmic detail
 4. Deployment-Level Design Elements
 Deployment-level design elements indicate how software functionality and subsystems
will be allocated within the physical computing environment that will support the
software
SOFTWARE ARCHITECTURE

• The software architecture is the structure or structures of the system, which comprise
software components, the externally visible properties of those components, and the
relationships among them.
• The architecture is not the operational software.

Three key reasons that software architecture is important:

• Software architecture provides a representation that facilitates communication among
all stakeholders
• The architecture highlights early design decisions that will have a profound impact on
all software engineering work that follows.
• Architecture “constitutes a relatively small, intellectually graspable model of how the
system is structured and how its components work together”

ARCHITECTURAL STYLES
• The software exhibits one of many architectural styles.
• Each style describes a system category that encompasses
(1) a set of components that perform a function required by a system,
(2) a set of connectors that enable “communication, coordination and cooperation”
(3) constraints that define how components can be integrated to form the system

1. Data Centred Architecture:

 A data store resides at the center of this architecture

 It is accessed frequently by other components that update, add, delete, or otherwise modify
data within the store.
 Existing components can be changed and new client components added
 Data can be passed among clients using the blackboard mechanism (i.e., the
blackboard component serves to coordinate the transfer of information between
clients).
 Client components independently execute processes.
2. Data Flow Architecture:

 This architecture is applied when input data are to be transformed through a series of
computational or manipulative components into output data.
 A pipe-and-filter pattern has a set of components, called filters , connected by pipes that
transmit data from one component to the next.
 Each filter works independently of those components upstream and downstream, is
designed to expect data input of a certain form, and produces data output (to the next
filter) of a specified form.
 However, the filter does not require knowledge of the workings of its neighboring
filters
 If the data flow degenerates into a single line of transforms, it is termed batch
sequential .

3. Call and Return Architecture

 This architectural style enables you to achieve a program structure that is relatively easy
to modify and scale.
 A number of substyles exist within this category
1. Main program/subprogram architectures - Here a “main” program invokes a
number of program components, which in turn may invoke still other
components.
2. Remote procedure call architectures. The components of a main program/
subprogram architecture are distributed across multiple computers on a
network.
4. OBJECT ORIENTED ARCHITECTURE:

 The components of a system encapsulate data and the operations that must be applied to
manipulate the data.
 Communication and coordination between components are accomplished via message
passing.

5. LAYERED ARCHITECTURE

 A number of different layers are defined

 At the outer layer, components service user interface operations.
 At the inner layer, components perform operating system interfacing.
 Intermediate layers provide utility services and application software functions.
 ARCHITECTURAL CONSIDERATIONS

• Economy —Many software architectures suffer from unnecessary complexity - unnecessary

features or non functional requirements (e.g., reusability when it serves no purpose). The best
software depends on abstraction to reduce unnecessary detail.
• Visibility — Architectural decisions and the reasons for them should be obvious to software
engineers who examine the model at a later time. Poor visibility arises when important design
and domain concepts are poorly communicated to those who must complete the design and
implement the system.
• Spacing— Separation of concerns in a design that is sometimes referred to as spacing. Sufficient
spacing leads to modular designs, but too much spacing leads to fragmentation and loss of
visibility.
• Symmetry —Architectural symmetry implies that a system is consistent and balanced in its
attributes. Symmetric designs are easier to understand, comprehend, and communicate.
• Emergence —Emergent, self-organized behavior and control are often the key to creating
scalable, efficient, and economic software architectures.

COMPONENT LEVEL DESIGN - WHAT IS A COMPONENT?

• A component is a modular building block for computer software.

• The component is defined as “a modular, deployable, and replaceable part
• In the context of object-oriented software engineering,
• a component contains a set of collaborating classes.
• Each class within a component has been fully elaborated to include all attributes and operations
• In the context of traditional software engineering,
• a component is a functional element of a program that incorporates processing logic, the
internal data structures, and an interface and data to be passed to it.
• A traditional component, also called a module serves one of three important roles:
(1) a control component that coordinates the invocation of all other problem
(2) a problem domain component that implements a complete or partial function
(3) an infrastructure component that is responsible for functions that support the
processing

DESIGNING CLASS-BASED COMPONENTS

 To create designs that are more amenable to change and to reduce the propagation of
side effects when changes do occur

1. The Open-Closed Principle (OCP).

 “A module [component] should be open for extension but closed for modification”.
 you should specify the component in a way that allows it to be extended without the
need to make internal modifications to the component itself.
 2. The Liskov Substitution Principle (LSP).
 “Subclasses should be substitutable for their base classes”
 This suggests that a component that uses a base class should continue to function properly
if a class derived from the base class is passed to the component instead.

3. Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on

concretions”

4. The Interface Segregation Principle (ISP). “Many client-specific interfaces are better than one
general purpose interface”

5. The Release Reuse Equivalency Principle (REP). “The granule of reuse is the granule of
release”.

6. The Common Closure Principle (CCP). “ Classes that change together belong together.”
Classes should be packaged cohesively. That is, when classes are packaged as part of a design,
they should address the same functional or behavioural area.

7. The Common Reuse Principle (CRP). “ Classes that aren’t reused together should not be
grouped together” . When one or more classes with a package changes, the release number of the
package changes

DESIGN LEVEL GUIDELINES

Components.
• Naming conventions should be established for components that are specifi ed as part of the
architectural model and then refined and elaborated as part of the component-level model.
• Architectural component names should be drawn from the problem domain and should have
meaning to all stakeholders who view the architectural model
Interfaces. Interfaces provide important information about communication and collaboration .
Dependencies and Inheritance. For improved readability, it is a good idea to model dependencies from
left to right and inheritance from bottom (derived classes) to top (base classes).
• In addition, components’ interdependencies should be represented via interfaces, rather than by
representation of a component-to- component dependency

CONDUCTING COMPONENT LEVEL DESIGN

• Step 1. Identify all design classes that correspond to the problem domain.
• Step 2. Identify all design classes that correspond to the infrastructure domain.
• Step 3. Elaborate all design classes that are not acquired as reusable components.
• Step 3a. Specify message details when classes or components collaborate.
• Step 3b. Identify appropriate interfaces for each component.
• Step 3c. Elaborate attributes and define data types and data structures required to implement them.
 • Step 3d. Describe processing flow within each operation in detail.
• Step 4. Describe persistent data sources (databases and files) and identify the classes required to
manage them.
• Step 5. Develop and elaborate behavioral representations for a class or component.
• Step 6. Elaborate deployment diagrams to provide additional implementation detail.
• Step 7. Refactor every component-level design representation and always consider alternatives.

COMPONENT LEVEL DESIGN FOR WEB-APPS

• WebApp component is
• (1) a well-defined cohesive function that manipulates content or provides computational or
data processing for an end user or
• (2) a cohesive package of content and functionality that provides the end user with some
required capability

Content Design at the Component Level

• Content design at the component level focuses on content objects and the manner in which they
may be packaged for presentation to a WebApp end user.
• In many cases, content objects need not be organized as components and can be manipulated
individually

Functional Design at the Component Level

• WebApp functionality is delivered as a series of components developed in parallel with the

information architecture to ensure consistency.
• During architectural design, WebApp content and functionality are combined to create a
functional architecture.
• A functional architecture is a representation of the functional domain of the WebApp and
describes the key functional components in the WebApp and how these components interact
with each other.