lecture 3 print 6

8/16/2019 Lecture 3 Print 6

1/12

1

Lecture III

2

Requirements/Systems analyst

• Person performing the tasks of determining

the requirements for a proposed softwaresystem

– (problem analysis) breaking down what the

customer wants into discrete requirements

3

Requirements

• Goal of requirements phase

– understand the customer’s problems and needs

• What is requirements?

– An expression of desired behaviour

– Deals with objects/entities, states they can bein, and functions that are performed to changestate or object characteristics

– Designates what behaviour the customer wantswithout saying how the behaviour will be

realised 4

Specification and Design

• Specification makes decisions on which

requirements will be fulfilled by our software

system

– As opposed to those that are addressed by special

purpose hardware devices, by other software

systems or by human operator or users

• In design, a plan is devised as to how the

specified behaviour will be implemented

5 6


2/12

7 8

Requirements process

9

Requirements Process -

Elicitation

• Collecting the user requirements by:

– Asking questions

– Examining current behaviour

– Demonstrating similar systems

10

Requirements Process - Analysis

• Understanding and modelling the desired behaviour

– Modelling or prototyping the requirementshelps us to better understand the required

behaviour

– Also raises additional questions about what thecustomer wants to happen in certain situations

• May expose problems or omissions in ourmodels that cause us to revisit the customer

and revise our models

11

Requirements Process - Specification

• Documenting the behaviour of the proposed

software system

– Requirements are well understood

– Then it is decided which parts of the required

behaviour will be implemented in this software

system

12

Requirements Process - Validation

• Checking that our specification matches the

user’s requirements

– Matches developer’s specifications with user’s

expectations of the final product

• May expose problems or omissions in our

specifications that cause us to revisit the

customer and revise our specifications


3/12

13

Requirements Process – Software

Requirements Specifications (SRS)

• Eventual outcome of the requirements process

• Is used to communicate to the other software

developers (designers, testers, maintainers)

how the final product ought to behave

14

Requirements Elicitation

• Critical part of the process

• Must use a variety of the techniques to

determine what the users and the customers

really want

• Discussion with everyone who has a stake in the

system and coalescing these different views into

a coherent set of requirements

15

Stakeholders in Requirements –

Elicitation Process

1. Clients

2. Customer

3. Users

4. Domain Experts

5. Market Researchers

6. Lawyers or auditors

7. Software engineers or other technology experts

16

Stakeholders in Requirements

Elicitation Process• Clients

– Pay for software to be developed

– Ultimate stakeholders as they have final say on what product does

• Customers

– Buy software after it is developed

• Users

– Experts on how current system works (most usefulfeatures, features that need improvement)

– Need to understand particular needs of special groups(differently-abled individuals, persons unfamiliar withcomputers, expert users)

17


Elicitation Process

• Domain experts

– Familiar with the problem that software must automate(financial expert for a financial package, meteorologistfor software to model weather)

– Also know about kinds of environment to which product will be exposed

• Market Researchers

– Conduct surveys to determine future trends and potential customers’ needs

18


Elicitation Process

• Lawyers/auditors

– Familiar with government, safety or legal requirements(tax expert ensures payroll package adheres to tax law,experts on standards which are relevant to product’s

functions)

• Software Engineers/other technology experts

– Ensures that the product is technically andeconomically feasible

– Educate customer about innovative technology,recommend new functionality taking advantage of thesetechnologies, and can estimate cost and developmenttime


4/12

19 20

21

Techniques for Eliciting Requirements

1. Interviewing stakeholders

2. Reviewing available documentation

3. Observing current system (if one exists)

4. Apprenticing with users

5. Interviewing users/stakeholders in groups

6. Using Domain-specific strategies

7. Brainstorming22


• Interviewing stakeholders

– To capture the many views of the system and how it shouldwork

• Reviewing available documentation

– Documented procedures of manual tasks

– Specifications or user manuals of automated system

• Observing current system (if one exists)

– Gather objective information about how users perform theirtasks

– Better understand the system that the developers are about to

automate or change

23


• Apprenticing with users

– Learn more about users’ tasks in more detail as the user performs them

• Interviewing users/stakeholders in groups

– So that they will be inspired by one another’s ideas

• Using domain-specific strategies

– To ensure that stakeholders consider specific types ofrequirements that are relevant to their particular situations

• Brainstorming with current and potential users about howto improve the proposed product

24

Types of Requirements – Functional

Requirements

• Describes a required behaviour in terms of

required activities

– e.g. reactions to inputs, states of each entity before

and after an activity occurs

• Defined boundaries of a solution space for our

problem

– Solution space is the set of possible ways that

software can be designed to implement the

requirements


5/12

25

Types of Requirements – Quality / Non-

Functional Requirements

• Describes some quality characteristic that

the software solution must posses

– e.g. fast response time, ease of use, high

reliability and low maintenance costs

• Design criteria that can be optimised and

used to choose among alternative

implementations of functional requirements

26

Make Requirements Testable

• Make requirements testable so the conclusion

of whether or not a proposed solution meetsthe requirement, must not vary according to

who is doing the evaluation

• Fit criteria

– Objective standards for judging whether a

proposed solution satisfies the requirements

27

Constraints on Requirements – Design

Constraints

• Design constraint

– Design decision that has already been made andthat restricts the set of solutions to our problem

• e.g. choice of platform or interface components

• Process constraint

– Restriction on the techniques or resources thatcan be used to build the system

• e.g. customer may insist that we use agile methods,so that they can use early versions of the system

while we continue to add features28

Requirements Problem - Conflict

• May encounter conflicting ideas of what

requirements ought to be, when eliciting

from stakeholders

• Possible solutions are

– Ask customer to prioritise requirements

– Negotiation

29

Conflict Solutions – Customer

prioritises requirements

• Helps customer reflect on which of requestedservices and features are most essential

• Loose prioritisation scheme separates requirementsinto 3 categories

– Essential Requirements that absolutely must be met

– Desirable Requirements that are highly desirable butnot necessary

– Optional Requirements that are possible but could beeliminated

30

Conflict Solutions – Negotiation

• Requires skills, patience and experience in

finding mutually acceptable solutions

• With effective negotiation, stakeholders will – understand and appreciate each other’s

fundamental needs and

– strive for a resolution that satisfies everyone


6/12

31

Different Purposes of

RequirementsTo explain their

understanding of how the

system would behave

Requirements analysts

and their clients

To help ensure that the

system enhancements do

not interfere with the

system’s original intent

Maintenance team

To derive a suite of

acceptance testsTest team

Used as constraints on what

would be considered an

acceptable solution

Designers

32

Requirements Documents1. Requirements Definition

– Aimed at a business audience, such as clients,customers and users

– Complete listing of everything customer wants to

achieve – Written entirely in terms of environment, describing

how the environment will be affected by the proposedsystem

2. Requirements Specification

– Aimed at a technical audience, such as designers,testers and project managers

– Restates requirements as a specification of how proposed system will behave

– Written entirely in terms of environment, except thatrefers solely to environmental entities that areaccessible to the system via its interface

33

Characteristics of Requirements

1. Correctness

2. Consistency

3. Unambiguity

4. Completeness

5. Feasibility

6. Relevance

7. Testability

8. Traceability

34


1. Correctness

• Developer and customer should ensure conformity to

our understanding of the requirements

2. Consistency

• No conflicting requirements, as inconsistent

requirements cannot be satisfied simultaneously

3. Unambiguity

• Multiple readers of requirements should have

different but valid interpretations

35


4. Completeness

• Set of requirements is defined as complete if it

specifies required behaviour and output for all

possible inputs in all possible states under all poss ible

constraints

• Externally complete if all states, state changes,

inputs, products, and constraints are described by

some requirement

• Internally complete if there are no undefined terms

among the requirements

36


5. Feasibility

• Existence of a solution to customer’s need

6. Relevance

• Indirectly related to customer’s need or may restrictdevelopers unnecessarily

7. Testability• Existence acceptance tests that would clearly

demonstrate whether the eventual product meets therequirements

8. Traceability

• Organisation of requirements for easy reference

• There should be correspondence between every entryin the requirement definition and requirementsspecification, and vice versa


7/12

37

Purpose of characteristics

• Help in making the decision when we have

collected enough information

• Also when we need to learn more about

what a particular requirement means

38

Purpose of characteristics

• The degree to which we want to satisfy these

characteristics will affect:

– Type of information that we gather duringrequirements elicitation, and how comprehensive we

want to be

– Specification language we choose to express the

requirements and the validation and verification

checks that we eventually perform to assess the

requirements

39 40

41 42


8/12

43 44

45 46

47 48


9/12

49 50

51 52

53 54


10/12

55 56

What are crucial process steps of requirement

engineering ? Discuss with the help of a diagram

What do you understand with the term

“requirements elicitation”?

What are components of a use case diagram.

Explain their usage with the help of an example

Draw the E–R diagram for a hotel reception desk

management

Questions

57

End of Lesson III

Thank you

58

CURRENT INVENTORY

DAMAGED INVENTORY SHIPPED INVENTORY

DATABASE

REMOVED INVENTORY

INVENTORY ANALYSIS

TRENDING

SPARE MANAGEMENT DATA FLOW

USER INTERFACE

ADD FAULTY ADD RMA NO.ADD INVENTORY ADD SITE ID

Diagram – 3

Some examples of E-R Diagrams

59

FAULT MANAGEMENT DATA FLOW

USER INTERFACE

ACTIVE OUTAGE

PRE-SUBMISSION

OUTAGE REPORT

SUPPORT ENGINEERS

RESTORED OUTAGES

SPARE MANAGEMENT

ACTIVE WORKS

PRE-SUBMISSION

PLANNED WORKS

SUPPORT ENGINEERS

COMPLETED WORKS

SITE MANAGEMENT

PLANNED WORKS OUTAGE REPORTING

DATABASE

C

US

TOM

ER

AREA

60

Let us do one E-R diagram for

Grade Sheet building


11/12

61

SRS

Interviews/ Questions/ Requirement Analysis

Scope and Specifications

What a Grade Sheet will have now?

Student ID? Name?

Is Grade Sheet for a specific semester? Or for whole program,

showing the history of all courses in all semesters of a specific

student?

Is there any change in the Grading Scheme over the time ?

Is there any change in the course codes and course titles?

Grade Sheet Building

62

What are the entities in a Grade Sheet?

ID

Name

Semester Details with Year and Month

List of Courses

Grades obtained

CGPA for that semester


63

Do we need the Teacher Information?

What is a Faculty?

Who offer the courses? And to who?

What is a class?

Do all the students in a class belong to one faculty?

Do we need to know the answers for the above?

If a student gets F grade and then repeats the same course

and gets another grade now; how that information should

be reflected?


64

What are the entities in a Grade Sheet?

ID

Name

Semester Details with Year and Month

List of Courses

Grades obtained

CGPA for that semester


65

What are the Objects?

Student

Teacher Course

Grade

Class

Faculty


66

What Functions we do need?

Structure for a student?

Structure for a teacher?

Adding a teacher/update/ removing

Similarly a student?

Similarly a course?

How we determine the final mark?

How we determine the grade?

How CGPA is computed?



12/12

67

What Technologies do we use to develop

this application?

Who enter the marks? [Inputs?]

Who will see the grades? [outputs?]

Who will verify these ? [verification or

validation?]


68

Develop DFDs

Develop E-R Diagrams

Decide who does what?

Determine the Team Size

Determine the Time Frame for the project
