Loading
Software
Requirements and Requirements Engineering
The problems which software engineers are called to solve are often
immensely complex. Understanding the nature of the problem can be very
difficult. If the system is new, there is no existing system to help understand
the nature of the problem. Consequently, it is difficult to establish exactly
what the system should do. The process of establishing the services the system
should provide and the constraints under which it must operate is called requirement
engineering. The term "engineering" means that a systematic
process is used to derive a definition of the software system which is to be
developed.
System requirements should set out what the system should do rather than how this is done. System requirements may be either functional or
non-functional requirements:
(i) Functional
Requirements: These are statements of services the
system should react to particular inputs and how system should behave in
particular situations. In some cases, the functional requirements may also
explicitly state what the system should not do.
(ii) Non - functional
Requirements: These are constraints on the services
or functions offered by the system. They include timing constraints,
constraints on the development process, standards and so on.
The requirements engineering process should
normally involve writing a requirements
definition then expanding this into a requirements
specifications.
Requirements definition and requirements
specifications may be defined & differentiated as follows:
(1) A requirements definition is a statement,
in a natural language plus diagrams of what services the system is expected to
provide and the constraints under which it must operate. It is generated using
customer-supplied information. Requirements definitions are customer-oriented
descriptions of what the system should do.
(2)
A requirements specification is
a structured document which sets out the system services in detail. It should
be more precise descriptions of the system’s functionality and the constraints
on its operation. They are intended to specify the system for software
designers so they are sometimes called functional specifications.
System
Models
A system model is an abstraction of the system
to be developed. Different types of system models contribute in different ways
to our understanding of the system. They are an important bridge between the
analysis and design processes.
Different types of system models are based on different approaches to
abstraction. A data-flow model (for
example) concentrates on the flow of data and the functional transformations on
that data. It leaves out details of the data structures. By contrast, an entity-relationship model is intended to
document the system data and its relationships without concern for the
functions in the system.
v Data-Flow Model or Data-Flow
Diagram (DFD)
¨
DFD is a
system modeling tool.
¨
DFD is a
graphical technique that depicts the information flow and the transform applied
as data moves from input to output.
¨
DFD is the
most popular and important representation in the system modeling.
¨
It is a
general technique used in many areas.
¨
DFD is
also called Bubble chart, Bubble
diagram, Process model, Work flow diagram.
¨
DFD
represents flow of data in the system not flow of control neither it is a flow
chart.
Ø
The basic building blocks of a DFD:
§
Process (a bubble, a function or a
transformation)
- how inputs are transformed or changed into
outputs.
- A process is represented graphically as a circle. Other alternative includes a rectangle with rounded edges.
§
Data Flow
- It is a named
arrow or labeled arrow. The
directions of the arrow describe the movement
of data or physical materials from one part of the system to another part.
§
Data Store
- It is used to model a collection of data
packets (files, tapes, punched cards, etc.) at rest which store relevant
information for use by one or more processes.
- It is represented by two parallel lines.
There is also other alternative i.e. an open ended box.
§
Terminator or External Entity
- It represents external entities with which
the system communicates. A terminator can be a person, a group of people. They
are outside the control of the system that is being modeled. It may also be
another system.
- External entities involved in the process transform
(both input and output)
- It is graphically represented as a rectangle.
¨
A DFD may
be used to represent a computer-based system at any level of abstraction.
¨
In fact,
DFDs are partitioned into levels that represent increasing information flow and
functional details.
¨
Level-0 DFD is called Context Diagram or
Fundamental System Model.
¨
Level-1 DFD is called Overview Diagram.
¨
Other
subsequent levels are named according to their central theme or main activity.
¨
Context
Diagram views the entire system as one process.
¨
Context
Diagram contains a single bubble to depict the entire system element with input
boxes and output boxes.
¨
Subsequent
level DFDs may contain more than one bubble to explain more details of the process
being modeled.
Use of
Dataflow Diagrams:
Problem Description:
When a student wants to enroll in a course, he makes a class request to the
enrollment department. There are 3 officers in the enrollment department. After
receiving the request, one officer enroll the student in the course and store
the student and course data into a student-class file. Another one is
responsible for collecting student fee payment, issuing receipts and handling
payment information of a student payment file. There is one more officer
producing different reports to the student who has been enrolled in a course,
produce a class roster to the corresponding professor, and produce enrollment
statistics to register.
Fig. DFD for the course enrolment system
Assignment: Draw a Context Diagram and DFD for the
Restaurant System.
Data
Dictionary
¨
Though the
DFD represents graphically the flow of information in a system, it is not
sufficient enough to describe the purpose
¨
of various
labels or captions, such as the purpose of input or output elements etc. In
order to detail out these labels and captions, a Data Dictionary is used which explains the nature and purpose of
data or information involved in a DFD.
¨
A Data Dictionary is an important tool for
maintaining information about system entities throughout the lifetime of a
project. It can support any kind of system model. Entries may be added at any
time during analysis and design.
v Entity-Relationship Model or Entity-Relationship Diagram (ERD)
¨
The E-R
Data Model views the real world as a set of basic entities (objects) and
relationship among these objects.
¨
It is
intended primarily to help the design process.
¨
An entity
is a distinguishable object that exists.
¨
Each
entity has associated with it a set of attributes describing it.
Eg.
Number and balance for an account entity.
¨
A
relationship is an association among several entities.
Eg.
A CustAcct relationship associates a customer with each account he or she has.
¨
The set or
collection of all entities or relationships of the same type are called the
entity set or relationship set respectively.
¨
Another
essential element of the E-R diagram is the mapping
cardinalities, which express the number of entities to which another entity
can be associated via a relationship set.
Ø
The Notations for E-R Diagram:
 |
Rectangles:
represent entity sets
 |
Ellipses: represent attributes
Diamonds: represent
relationships among entity sets
Lines: link attributes to entity sets and entity
sets to relationships.
Fig. E-R Diagram showing the relationship set
between Customer and Account entities.
Mapping Cardinalities: express the number of entities to which another entity can be associated via
a relationship set. For binary relationship sets between entity sets A and B, the mapping cardinality must be one of:
1.
One-to-one: An entity in A is associated
with at most one entity in B, and an entity in B is associated with at most one
entity in A.
|
|
|
|
 |
|
 |
|
 |
2.
One-to-many: An entity in A is
associated with any number in B. An entity in B is associated with at most one
entity in A.
A
|
|
|
|
 |
3.
Many-to-one: An entity in A is
associated with at most one entity in B. An entity in B is associated with any
number in A.
A B
4.
Many-to-many: Entities in A and B are
associated with any number from each other.
|
|
|
|
 |
|
 |
¨
The appropriate mapping
cardinality for a particular relationship set depends on the real world being
modelled. We can think about the CustAcct relationship in this light.
¨
Cardinality Constraints: We express
cardinality constraints by drawing either a directed line (→), signifying
“one”, or an undirected line (─), signifying “many”, between the relationship
set and the entity set.
¨
E.g.: One-to-Many Relationship
§
A
Customer is associated with several accounts via CustAcct
§
An
Account is associated with at most one Customer via CustAcct
Fig. E-R Diagram showing One-to-Many Relationship
Software
Prototyping
Software prototyping is a model of the software
to be built through which requirements can be effectively derived. It is the
creation of a trial or demonstration system, so that the users can evaluate,
refine, and comment on the design before work on the actual product begins.
System prototypes allow users to experiment
with requirements and to see how the system supports their work. Prototyping is
therefore used to validate software requirements.
A software prototyping help to develop and
check the real requirements of the system.
v
The benefits of developing a prototype early in
the software process are:
(1)
Misunderstanding
between software developers and users may be identified as the system functions
are demonstrated.
(2)
Missing
user services may be detected.
(3)
Software
development staff may find incomplete and/or inconsistent requirements as the
prototype is developed.
(4)
The
prototype serves as a basis for writing the specification for a production
quality system
(5)
A
prototype system can be used for training users before the final system has
been delivered.
No comments:
Post a Comment