Software engineering lecture 3
This presentation is the property of its rightful owner.
Sponsored Links
1 / 15

SOFTWARE ENGINEERING LECTURE 3 PowerPoint PPT Presentation


  • 83 Views
  • Uploaded on
  • Presentation posted in: General

SOFTWARE ENGINEERING LECTURE 3. Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. THE BASIC WATERFALL MODEL. Requirements analysis. Design. Implementation. Testing. Maintenance. PROTOTYPING FOR REQUIREMENT ANALYSIS.

Download Presentation

SOFTWARE ENGINEERING LECTURE 3

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Software engineering lecture 3

SOFTWARE ENGINEERING LECTURE 3

  • Today: Requirements Analysis

  • Requirements tell us what the system should do - not how it should do it.


The basic waterfall model

THE BASIC WATERFALL MODEL

Requirements analysis

Design

Implementation

Testing

Maintenance


Prototyping for requirement analysis

PROTOTYPING FOR REQUIREMENT ANALYSIS

Requirements analysis - V&V

Design - V&V

Quick Design - V&V

Implementation

- V&V

Quick Implementa-tion - V&V

Testing - V&V

V&V = Verification and Validation

Maintenance

- V&V


Requirements analysis

REQUIREMENTS ANALYSIS

  • Aims at producing a requirements specification.

  • Is generally the most crucial phase of an average software project - if it succeeds then a complete failure is unlikely.

  • The requirements specification can be used as a basis for a contract.

  • If so, then the requirements specification will also be eventually used to evaluate if the software fulfills the requirements.


Requirements analysis1

… REQUIREMENTS ANALYSIS

  • First the requirements must somehow be extracted.

  • As users generally can not work with formal specifications, natural language specifications must often be used

  • Then the requirements must be documented to be used in the later stages of software development. Now a more formal specification method may be possible.


Requirement specification description techniques

REQUIREMENT SPECIFICATION DESCRIPTION TECHNIQUES

  • Natural language- Understandable for users

  • Graphical languages- Simple languages (like ER) work well in practice, but are usually not designed for other purposes than requirement specification.

  • General formal languages- Usually much too difficult to understand even for an above average user- You may be able to verify the system, but how can you verify the requirements?


Good requirements specification qualities

GOOD REQUIREMENTS SPECIFICATION QUALITIES

  • Complete

  • Accurate

  • Unambiguous

  • Verifiable (How can you verify ”user friendliness”?)

  • Consistent

  • Modifiable (also the requirements change)

  • Traceable (where has each requirement come from?)


Overall structure for req spec ansi ieee standard 830

OVERALL STRUCTURE FOR REQ. SPEC. (Ansi/IEEE Standard 830)

  • 1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, Acronyms and Abbreviations 1.4. References 1.5. Overview2. General Description 2.1. Product Perspective 2.2. Product Functions 2.3. User Characteristics 2.4. General Constraints 2.5. Assumptions and Dependencies3. Specific Requirements


Ansi ieee specific requirements

ANSI/IEEE: Specific requirements

  • 3. Specific requirements 3.1. Functional Requirements 3.2. External Interface Requirements 3.3. Performance Requirements 3.4 Design Constraints 3.4.1. Standards Compliance 3.4.2. Hardware Limitations … 3.5. Attributes 3.5.1. Security 3.5.2. Maintainability … 3.6. Other Requirements 3.6.1. Data Base …


Ansi ieee functional requirements

ANSI/IEEE: FUNCTIONAL REQUIREMENTS

  • 3.1. Functional Requirements 3.1.1. Functional Requirement 1 3.1.1.1 Introduction 3.1.1.2 Inputs 3.1.1.3 Processing 3.1.1.4 Outputs 3.1.2 Functional Requirement 2 … 3.1.n Functional Requirement n


Requirements specification an example

REQUIREMENTS SPECIFICATION - AN EXAMPLE

  • A specification for an imaginary library system

  • From Van Vliet’s book


Techniques for getting the requirements from users

TECHNIQUES FOR GETTING THE REQUIREMENTS FROM USERS

  • Asking- Interview- Questionnaire- ”Brainstorming” sessions

  • Analysing an existing system- We must understand how the new system will differ from any old such system

  • Analysing the environment- e.g. process analysis

  • Prototyping- Gives best feedback and more formal specifications but can be expensive


Requirements analysis what can go wrong

REQUIREMENTS ANALYSIS - What can go wrong?

  • Missing specifications- Happens often- Experience helps- Sometimes it is impossible to notice

  • Contradictions- Do not document the same thing many times- Integrate different users’ views with the users

  • Noise- Do not include material which does not contain relevant information


Requirement specification what can go wrong 2

REQUIREMENT SPECIFICATION - What can go wrong? (2)

  • Documenting a solution rather than the problem- If the users know some information technology, they want to start solving the problem as they express it.- Many formal (also graphical) methods tend to direct the process into this.

  • Unrealistic requirements- Although we model the problem rather than the solution, it is good to have some idea of what is possible.


Who should do requirement specification

WHO SHOULD DO REQUIREMENT SPECIFICATION?

  • Someone who can communicate with the users

  • Someone who has experience

  • Someone who knows similar systems and/or the application area

  • Someone who knows what is possible and how (and how much work is roughly needed).


  • Login