(1) What is Software Requirements about?
(2) Why do we need to have Software Requirements? (Important or not important?)
(3) When do we "make/buy/get or whatever" Software Requirements?
(4) Who is involved with Software Requirements? (Who builds, writes, etc... Who uses, ...)
(5) Where is Software Requirements used?
(6) How do we "make/buy/get or whatever" Software Requirements?
(7) How much effort or money or time should we spend on Software Requirements?
===========================================================
Software Requirements "is dependent on" System Requirements.
===========================================================
Go to SEF9 -09 June 10 2013 where 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
===========================================================
To find answers to all the above questions, read the attachments. We will discuss in class.
READ first, SVT-UserREquirements-doc.pdf
1.1 The purpose of this document is to provide the User Requirements descriptions for the proposed Satellite Vehicle Tracking (SVT) System for VMS Incorporated, a company involved in the management and logistical support for vehicle fleets in Malaysia.
bla bla bla.
After reading it, can you think of what would be the requirements for a FINANCIAL SYSTEM SOFTWARE project? Would it be similar to what you have read?
- System Requirements versus Software Requirements
===========================================================
System Requirements is the requirement descriptions for the overall system, covering hardware, software, installation, operations, etc. It must be described.
Software Requirements is the requirement descriptions for the software part of the system. It must be described.
- Functional, Non-Functional, Domain Requirements.
============================================================
FUNCTIONAL REQUIREMENTS
- describes what the system should do.
- describes the inputs, outputs, exceptions, etc, for the functions
- are verifiable (can be shown to be achievable or nor achievable)
NON-FUNCTIONAL REQUIREMENTS
- describe requirements to support the achievement of the functional requirements
- describe constraints that are applicable to the functional requirements
- describe emergent properties based on the functional requirements (like the response speed or memory requirements)
- Characteristics of SRS (Software Requirements Specifications)
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.
- Classification of specification types (system/software types)
=================================================================
(1) Software Requirements for an Information System
(2) Software Requirements for a Control System
(3) Software Requirements for Formal Systems
- Product Requirements versus Process Requirements.
=================================================================
PRODUCT ==> DESCRIBE WHAT THE PRODUCT LOOKS LIKE, HOW THE PRODUCT WORKS, ETC.
PROCESS ==> DESCRIBE THE PROCESS REQUIREMENTS OF BUILDING THE PRODUCT.
===========================================================
COMPLETENESS OF THE SRS DOCUMENT - Apply W5H2 principle
===========================================================
(1) What do we understand by completeness in SRS? (DESCRIBE COMPLETELY)
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.
===========================================================
- Operational specifications: CRUD, Events and States.
==============================================================
CRUD = Create, Review, Update and Delete (information)
EVENTS = Description of something ahappening, and reacting.(example: door open, door close, valve 50% open, light on, off, etc)
STATES = Description at any instant. (closed, open, temp, pressure, on, off)
- IEEE System Requirements Specifications (SyRS) - W5H2
- IEEE Software Requirements Specifications (SRS) - W5H2
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
===========================================================
--
WASSALAM
wruslan.hahaha
Microsoft Word Version
Return to Software Engineering Fundamentals (SEF9MMUWRY)
Previous Topic: 28 Project Work Assignment (Project Title)
Next Topic: 30 Tutorial exercise for Software Requirements (02 July 2013)
0 comments:
Post a Comment