Page 66 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes makes clear that these are desirable or essential features of a document but makes clear that the
ways in which these components are provided depends on the designers of the documentation.
Some (such as a table of contents) are clearly separate sections; other components such as
navigational features will be found throughout the document. However, many organizations
will use the standard as a guide and will not necessarily include all of the components in such
circumstances, there are some minimal structuring guidelines that we believe should always
be followed, all documents, however short, should have a cover page which identifies the
project, the document, the author, the date of production, the type of document, configuration
management and quality assurance information, the intended recipients of the document, and the
confidentiality class of the document. It should also include information for document retrieval
(an abstract or keywords) and a copyright notice. Requirements have to be specified using some
specification language. Though formal notations exist for specifying specific properties of the
system, natural languages are now most often used for specifying requirements. When formal
languages are employed, they are often used to specify particular properties or for specific
parts of the system, as part of the overall SRS. All the requirements for a system, stated using a
formal notation or natural language, have to be included in a document that is clear and concise.
For this, it is necessary to properly organize the requirements document. Here we discuss the
organization based on the IEEE guide to software requirements specification.
The detailed requirements section describes the details of the requirements that a developer
needs to know for designing and developing the system. This is typically the largest and most
important part of the document. For this section, different organizations have been suggested
in the standard. These requirements can be organized by the modes of operation, user class,
object, feature, stimulus, or functional hierarchy one method to organize the specific requirements
is to first specify the external interfaces, followed by functional requirements, performance
requirements, design constraints, and system attributes. The external interface requirements
section specifies all the interfaces of the software: to people, other software, hardware, and
other systems. User interfaces are clearly a very important component; they specify each human
interface the system plans to have, including screen formats, contents of menus, and command
structure. In hardware interfaces, the logical characteristics of each interface between the software
and hardware on which the software can run are specified. Essentially, any assumptions the
software is making about the hardware are listed here. In software interfaces, all other software
that is needed for this software to run is specified, along with the interfaces. Communication
interfaces need to be specified if the software communicates with other entities in other machines.

Prepare a DFD for the flow of data in an organization.

Requirements Specification to the Software
Process with ACUS

mproving the software process to improve overall software development has been an
on-going endeavour for both industrial practitioners and academics for many years.
IIn software engineering, and in particular the software process area, issues relating to
requirements engineering (RE) have been repeatedly cited. Requirements specification is
regarded as a critical stage of software development, with the claim that software development
problems could be better addressed with Bgood RE practice, While software engineering is
benefiting from the development of models and standards for software process improvement
and assessment such as the ISO 9001 standard for quality management systems, and the
Contd...

60 LOVELY PROFESSIONAL UNIVERSITY