User Requirements-Software Requirement-Lecture Slides, Slides of Software Project Management

Download User Requirements-Software Requirement-Lecture Slides and more Slides Software Project Management in PDF only on Docsity!

Software Requirements

Lecture # 4

2

Recap of Last Three Lectures

• Kinds of requirements
  • Functional– Non-functional– Domain– Inverse– Design and implementation constraints

4

Another View of Requirements

• In general requirements can be viewed

as – User/customer requirements

OR

• System contract requirements

User/Customer Requirements

7

User/Customer Requirements - 2• These are understandable by users,

who have no, or little, technicalknowledge

• System design characteristics should

be avoided as much as possible

8

User/Customer Requirements - 3• It is a good practice to separate user

requirements from more detailedsystem requirements in a requirementsdocument

10

User/Customer Requirements - 5• The rationale associated with

requirements is very important. Ithelps in managing changes torequirements

System Contract Requirements

13

System Contract Requirements - 2• They are used by the designers and

developers as the starting point forsystem design

• They should be understood by

technical staff of the customerorganization and the development team

14

System Contract Requirements - 3• In principle, these requirements should

also state ‘what’ the system does,rather than ‘how’ it is implemented

• However, with the level of details

needed to specify the systemcompletely, it is not possible toexclude all design information

16

System Contract Requirements - 5• Natural language is often used to

describe system requirements

• Some specification languages may be

used with natural language, which addstructure to specifications and reduceambiguity

17

System Contract Requirements - 6• Unified Modeling Language (UML) is

a specification language, which hasbecome the de-facto standard formodeling requirements

19

Requirements Problems - 1

• The requirements don’t reflect the real

needs of the customer for the system

• Requirements are inconsistent and/or

incomplete

• It is expensive to make changes to

requirements after they have beenagreed upon

20

Requirements Problems - 2

• There are misunderstandings between

customers, those developing thesystem requirements, and softwareengineers developing or maintainingthe system