SEF9 - 09 SWEBOK + SDLC(Waterfall) + System Requirements + Software Requirements

SWEBOK = Software Engineering Body of Knowledge

http://www.computer.org/portal/web/swebok

The purposes of the SWEBOK Guide are:

(1) to characterize the contents of the software engineering discipline;

(2) to promote a consistent view of software engineering worldwide;

(3) to clarify the place of, and set the boundary of, software engineering with respect to other disciplines;

(4) to provide a foundation for training materials and curriculum development;

(5) to provide a basis for certification and licensing of software engineers.

As of the 2004 edition, the SWEBOK guide define ten(10) Knowledge Areas (KAs) within the field of software engineering:

TECHNICAL AREAS (5 KAs) OF SOFTWARE ENGINEERING
Also called the Software Development Life Cycle (SDLC) processes

REFER TO DIAGRAM at http://en.wikipedia.org/wiki/Waterfall_model <== Must go here.

* Software requirements
* Software design
* Software construction
* Software testing
* Software maintenance

MANAGEMENT AREAS (5 KAs) OF SOFTWARE ENGINEERING

* Software configuration management
* Software engineering management
* Software engineering process
* Software engineering tools and methods
* Software quality

IMPORTANT: The TECHNICAL AREAS and MANAGEMENT AREAS of Software Engineering must be looked at and implemented simultaneously.

Who says software engineering (SE) is all technical? Ha ha ha. Look at the above KAs in SWEBOK. In this SEF course, we will learn the foundations about all of them.

===========================================================
Software Requirements "is dependent on" System Requirements.
===========================================================
We attached both the IEEE System Requirements and IEEE Software Requirements documents.

SYSTEM REQUIREMENTS SPECIFICATIONS (IEEE Std 1233 - 1989) Note: SyRS NOT SRS

This guide provides guidance for the development of a set of requirements that, when realized, will satisfy an expressed need. In this guide that set of requirements will be called the System Requirements Specification (SyRS).

SYSTEM: Its definition: An interdependent group of people, objects, and procedures constituted to achieve defined objectives or some operational role by performing specified functions. A complete system includes all of the associated equipment, facilities, material, computer programs, firmware, technical documentation, services, and personnel required for operations and support to the degree necessary for self-sufficient use in its intended environment.

(1) Developing an SyRS includes the:

- identification,
- organization,
- presentation,
- and modification

of the requirements.

(2) This guide addresses conditions for incorporating operational concepts, design constraints, and design configuration requirements into the specification.

(3) This guide also addresses the necessary characteristics and qualities of individual requirements and the set of all requirements.

(4) This guide does not specify industry-wide system specification standards nor state a mandatory System Requirements Specification.

(5) This guide is written under the premise that the current state of the art of system development does not warrant or support a formal standards document

===========================================================
SOFTWARE REQUIREMENTS

(1) Software requirements (DETAILED TOPICS)

- System Requirements versus Software Requirements
- Functional, Non-Functional, Domain Requirements.
- Characteristics of SRS (Software Requirements Specifications)
- Classification of specification types (system/software types)
- Product Requirements versus Process Requirements.
- Operational specifications: CRUD, Events and States.
- Data flow diagram, state transition diagrams.
- Description specification: Informal versus Formal
- ER diagram, logic specification and algebraic specification.
- Formal Specifications (Safety and Mission Critical)
- Requirements Elicitation, Requirements Reviews, Requirements Audits,
- IEEE System Requirements Specifications (SyRS) - W5H2
- IEEE Software Requirements Specifications (SRS) - W5H2

APPLY THE W5H2 PRINCIPLE TO SOFTWARE REQUIREMENTS
===========================================================

(1) What is Software Requirements?

Software requirements is a sub-field of Software Engineering that deals with the elicitation, analysis, specification, and validation of requirements for software. The output is a "WRITTEN DOCUMENT" called the Software Requirements Specifications (SRS) document.

REFERENCE: http://en.wikipedia.org/wiki/Software_requirements

(2) Why do we need Software Requirements?
(3) Who creates or produces the Software Requirements?
(4) When do we produce the Software Requirements?
(5) Where do we apply or utilize the Software Requirements?
(6) How do we create or produce the Software Requirements?
(7) How much information and effort is required to produce the Sof

===========================================================

The basic SRS outline is given below:

1. Introduction

1.1. purpose
1.2. scope
1.3. definitions,acronyms and abbreviations
1.4. references
1.5. overview

2. Overall Descriptions

2.1. product perspective
2.2. product functions
2.3. user characteristics
2.4. assumptions and dependencies

3. Specific requirements

3.1. External interfaces
3.2. Functional requirements
3.3. performance requirements
3.4. logical database requirements
3.5. Design constraints
3.6. Software system attributes
3.7. organizing the specific requirements
3.8. additional comments

4. supporting information

4.1. table of contents and index
4.2. appendixes

===========================================================
EXAMPLES: (See attached documents)

(1) Software Requirements for an Information System

(2) Software Requirements for a Control System
(3) Software Requirements for Formal Systems

===========================================================
COMPLETENESS OF THE SRS DOCUMENT - Apply W5H2 principle
===========================================================

(1) What do we understand by completeness in SRS?

COMPLETENESS (FEDUPAAR acronym) IF AND ONLY IF CONDITION
===========================================================

F - Describe the FUNCTIONALITY required in the software (e.g. what functions the software is supposed to do, execute, ..., etc)

E - Describe the EXTERNAL Interfaces (e.g. connecting to other systems, hardware systems, protocols, databases, ..., etc)

D - Describe the DESIGN constraints in the software (e.g. limited only to ..., does not include ...,etc)

U - Describe the USAGE of the software (e.g. users will need to do this, that, follow these steps ..., etc)

P - Describe the PERFORMANCE requirements of the software (e.g. memory, speed of response, stability, availability, ..., etc)

A - Describe the ATTRIBUTES of components in the software (e.g. fields, sizes, shapes, colors, types, ..., etc)

A - Describe the ACTIONS or RESPONSES of the software (e.g. pre-conditions, post-conditions, success conditions ==> act this way, ... etc)

R - Describe the REFERENCES for the requirements of the software (e.g. standards document, operating manuals, UML diagrams, company meeting documents, company records and documents, ..., etc)

===========================================================
(2) Why is it important to have completeness in SRS?

THINK CAREFULLY - about missing "any one or more" of the items in FEDUPAAR above, what will happen?

Think about safety-critical or mission-critical systems. Think about the implementors of the software (software designers, programmers, testers ?)


(3) Who is going to ensure completeness in SRS?

(4) When do we need completeness in SRS?

(5) Where is completeness in SRS applicable?

(6) How do we ensure completeness in SRS?

(7) How much effort is required for completeness in SRS?

===========================================================
CHARACTERISTICS OF REQUIREMENTS IN SRS DOCUMENT
===========================================================
REFERENCE-SRS: wget http://clusterlab.mmu.edu.my/sef5/05-IEEE-Std-830-1998-Software-Requirements-Specifications.pdf

Go to REFERENCE-SRS document, see page 10/37:

Since the SRS has a specific role to play in the software development process, the SRS writer(s) should be careful not to go beyond the bounds of that role. This means the SRS:

(a) Should correctly define all of the software requirements. A software requirement may exist because of the nature of the task to be solved or because of a special characteristic of the project.

(b) Should not describe any design or implementation details. These should be described in the design stage of the project.

(c) Should not impose additional constraints on the software. These are properly specified in other documents such as a software quality assurance plan. Therefore, a properly written SRS limits the range of valid designs, but does not specify any particular design.


4.3 Characteristics of a good SRS document
===========================================================

An SRS (i.e. the descriptions in the SRS) should be:

(a) Correct;

(b) Unambiguous;

(c) Complete;

(d) Consistent;

(e) Ranked for importance and/or stability;

(f) Verifiable;

(g) Modifiable;

(h) Traceable.

===========================================================

SOFTWARE REQUIREMENTS

Classification of specification types (Do them differently)

- Normal, Safety, or Mission Critical applications

- Depends on the system requirements, scope or boundary

- Depends on software applications for the system

===========================================================
Go to SWEBOK, Go to page 34 of 202

SCOPE OF ACTIVITIES IN REQUIREMENTS ENGINEERING
(SOFTWARE REQUIREMENTS NOT SYSTEM REQUIREMENTS)

In requirements, concentrate on WHAT (of functionalities) not HOW-TO-DO (of functionalities). WHY?

Operational specifications: CRUD, Events and States.

- Create, Review, Update, Delete - Information Systems

- States and Events - Control Systems (e.g. elevator, washing machine, etc)

- Using diagrams: e.g. UML Designs (OOD) http://en.wikipedia.org/wiki/Unified_Modeling_Language


The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software-intensive system under development.[1] UML offers a standard way to visualize a system's architectural blueprints.

===========================================================
References:

Good Book 1 (Chapter 7 - Requirements Engineering, Chapter 8 - Building the Analysis Model)

Good Book 2 (Chapters 6, 7, 8, 9 and 10) Figure 6.17 - The Structure of a Requirements Document


Data flow diagram (DFD),
http://en.wikipedia.org/wiki/Data_flow_diagram
===========================================================

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. DFDs can also be used for the visualization of data processing (structured design).

Entity Relationship Diagram (ERD),
http://en.wikipedia.org/wiki/Entity-relationship_model
===========================================================

In software engineering, an entity-relationship model (ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion. Diagrams created by this process are called entity-relationship diagrams, ER diagrams, or ERDs.

State transition diagrams(UML),
http://en.wikipedia.org/wiki/State_transition_diagram
===========================================================

A state diagram is a type of diagram used in computer science and related fields to describe the behavior of systems. State diagrams require that the system described is composed of a finite number of states; sometimes, this is indeed the case, while at other times this is a reasonable abstraction. There are many forms of state diagrams, which differ slightly and have different semantics.

Description specification: Informal versus Formal
http://en.wikipedia.org/wiki/Formal_specification
===========================================================

In computer science, a formal specification is a mathematical description of software or hardware that may be used to develop an implementation. It describes what the system should do, not (necessarily) how the system should do it. Given such a specification, it is possible to use formal verification techniques to demonstrate that a candidate system design is correct with respect to the specification.

Example: Intel Multi-Core CPU specifications.

FORMAL = logic specification and algebraic specification. (Formal languages)

Why Formal Specifications (Safety and Mission Critical)?

Formal methods are mathematical approaches to software and hardware computer-based system development from requirements, specification and design through to programming and implementation. They form an important theoretical underpinning for software engineering, especially where safety or security is involved. Formal methods are a useful adjunct to software testing since they help avoid errors and can also give a framework for testing. For industrial use, tool support is required.

QUALITY OF SPECIFICATIONS:
===========================================================
Requirements Elicitation, Requirements Reviews, Requirements Audits,

Important: When I review requirements, what questions should I ask?

Refer to Good Book 1, Chapter 7 Section 7.8 VALIDATING REQUIREMENTS.

Characteristics of a good SRS (IEEE Std 830 SRS - Page 10 of 37)

An SRS should be

- Correct;
- Unambiguous;
- Complete;
- Consistent;
- Ranked for importance and/or stability;
- Verifiable;
- Modifiable;
- Traceable.

An SRS is complete if, and only if, (satisfies ... FEDUPAAR) descriptions:

- Functionality
- External Interfaces
- Design Constraints (pre conditions, post conditions, expected results, etc)
- Usage of system/software
- Performance Measures
- Attributes descriptions
- Assumptions (of environment)
- References

===========================================================


--
WASSALAM
wruslan.hahaha

Attachments:
SEF-Example-software_requirements_for_control_system.pdf
SEF-Example-software-requirements-for_formal-specifications.pdf
SEF-Example-software_requirements_for_infomation_system.pdf
SEF-IEEE-Std-830-1998-Software-Requirements-Specifications.pdf
SEF-IEEE-Std-1233-1989-System-Requirements-Specifications.pdf
SEF-Software-Requirements-SWEBOK-2004.pdf
SEF-Official-IEEE-SWEBOK-2004.pdf.png
SEF-Software-Requirements-What-To-Avoid.pdf

Full Version with Microsoft Word Version and Attachments
Return to Software Engineering Fundamentals (SEF9MMUWRY)
Previous Topic: 08 Tutorial 01 SESSION Basic Linux Environment (TUE 04 JUN 2013)
Next Topic: 10 Useful Readings A - Questions and Answers (Q & A)