Software EngineeringLecture 8Systems Analysis: Concept and Principles

1

IntroductionRequirement Analysis the process

of discovering, refinement, modeling and specification in a software project.

Will always involve both the customer and system engineer, allowing the system engineer to achieve a set of objectives:◦ Specify software function and performance.◦ Indicate software interface with other system

elements.◦ Establish design constraints that the software

must meet.

2

Requirements AnalysisRequirement Analysis is also concerned

with the preparation of the Software Requirements Specification: ◦ A formal document that specifies in precise

terms the functional and performance requirements of the software.

◦ Specification document in turn will allow the developer and customer to assess quality once the software itself has been built.

The software developer performing Requirement analysis would often be known as the System Analyst.

3

Requirements Analysis TasksProblem RecognitionEvaluation and synthesisModelingSpecificationReview

4

Problem Recognition• Goal of analyst here is recognition

of the basic problem elements as perceived by user and customer.

• Understand software in the system context.

• Define software scope.• Analyst will also need to establish

contact with management and technical staff of the customer and software development organization.

5

Evaluation and Synthesis• The analyst must now evaluate the flow and

content of information.• Define and elaborate all software functions.• Understand software behavior in the context

of events that affect the system.• Establish system interface characteristics

and uncover design constraints.• Throughout this step, the emphasis is on

what must be done, not how it will be done.• This step will continue until both the analyst

and customer feels confident that software can be adequately specified for subsequent development steps.

6

ModelingThe analyst creates models of

the system in an effort to better understand data and control flow, functional processing, operational behaviour, and information content.

7

Modeling: roles

Aids in understanding the information, function and behavior of a system.

Makes requirement analysis task easier and more systematic.

It serves as a basis for creating specification for the software.

Becomes the focal point for review.

Becomes the foundation for design.

8

Specification The specification is a

representation of software that can be reviewed and approved by the customer.

Usually developed as a joint effort between the developer and the customer.

9

Specification Principles (Balzer and Goodman, 1986)

Separate functionality from implementation A process-oriented systems specification

language is required A specification must encompass the system

of which the software is component A specification must encompass the

environment in which the system operates A specification must be a cognitive model A specification must be operational A specification must be tolerant of

incompleteness and augmentable A specification must be localized and

loosely coupled 10

Review Review of analysis documents like

specification. Review should first be conducted at a

macroscopic level. Conducted by customer and

developer. Results in modifications to:

Functions. Performance. Information representation. Constraints. Validation criteria. 11

The System Analyst Responsibility of a system analyst is to

analyze and define systems of optimum performance, i.e. an output that fully meets management objectives

The analyst must also exhibit the ability to: Grasp abstract concept, partition them and

generate solutions based on each division. Understand implicit information, separate them

and treat them individually. Absorb pertinent facts from conflicting sources. Understand the customer environment. Apply hardware and/or software system elements

to the customer environment. Communicate well in written and verbal form.

12

Problems in Requirements Analysis Requirement analysis is a communication-

intensive activity where communication is concerned.

Miscommunication and omission often occur between the system analyst and customer.

Successful acquisition of information cannot be guaranteed. Analyst have difficulties: In getting pertinent (appropriate) information Handling large and complex problems, i.e. as

complexity increases, effort increases Accommodating changes that occur during and

after analysis

13

Communication TechniquesConduct a preliminary meeting or

interview.Facilitated Application Specification

Techniques (FAST) encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of solution, negotiate different approaches and specify a preliminary set of solution requirements.

14

FAST guidelinesConduct meeting at a neutral

side.Establish rulesPrepare an agendaDetermine the facilitator who

controls the meetingDetermine mechanism of the

meetingCreate a conducive environment

in order to meet the goals. 15

Quality Function DeploymentQuality Function Deployment (QFD) is

a quality management technique that translates the needs of the customer into technical requirements for software.

QFD concentrates on maximizing customer satisfaction from the software engineering process.

QFD emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process.

16

QFD three types of requirements

Normal RequirementsStated objectives/goals during meeting with the customer. E.g. Specific system functions.

Expexted RequirementsImplicit requirements, customer does not explicitly state them, their absence can cause significant dissatisfaction. E.g. Ease of human/machine interaction.

Exciting RequirementsBeyond customer’s expectation, very satisfying when present. E.g. Standard word processing software is equipped with page layout capabilities tha are quite pleasing and unexpected.

17

Use-CasesAs requirements are gathered as

part of informal meetings, FAST, or QFD, the analyst can create a set of scenarios that identify a thread of usage for the system to be constructed.

The scenario is called use-case, which provides a description of how the system will be used.

18

ActorTo create a use-case, the analyst

must first identify the different types of people (or devices) that use the system of product.

These actors actually represent 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.

An actor and a user are not the same thing.

19

Use Case

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

The use case describes the manner in which an actor interacts with the system.

In general, a use-case is simply a written narrative that describes the role of an actor as interaction with the system occurs.

20

A set of guidelines for requirements engineering (Davis, 1995)Understand the problem before

modelingDevelop prototypesRecord the origin of and the

reason for every requirementUse multiple view of

requirementsRank requirementsWork to eliminate ambiguity.

21

PartitioningProblems are often too large and

complex to be understood as a whole.

Partitioning decomposes a problem into its constituent parts.

Use the ‘divide and conquer’ method.

22

Prototyping

Prototype is a model of the software to be built, which is constructed for customer and developer assessment.

The prototyping paradigm can be either close-ended or open-ended.◦Close-ended, called throwaway

prototyping, serves solely as a rough demonstration of requirements, then discarded. The software is engineered using a different paradigm.

◦Open-ended, called evolutionary prototyping, the prototype is the first evolution of the finished system.

23

ReferencesPressman, Chapter 10-11

24