Software Requirement Specifications
The production of the requirements stage of the software development process is Software
Requirements Specifications (SRS) (also called a requirements document). This report lays a
foundation for software engineering activities and is constructing when entire requirements are elicited
and analyzed. SRS is a formal report, which acts as a representation of software that enables the
customers to review whether it (SRS) is according to their requirements. Also, it comprises user
requirements for a system as well as detailed specifications of the system requirements.
The SRS is a specification for a specific software product, program, or set of applications that perform
particular functions in a specific environment. It serves several goals depending on who is writing it.
First, the SRS could be written by the client of a system. Second, the SRS could be written by a developer
of the system. The two methods create entirely various situations and establish different purposes for
the document altogether. The first case, SRS, is used to define the needs and expectation of the users.
The second case, SRS, is written for various purposes and serves as a contract document between
customer and developer.
Requirements Analysis
Requirement analysis is significant and essential activity after elicitation. We analyze, refine, and
scrutinize the gathered requirements to make consistent and unambiguous requirements. This activity
reviews all requirements and may provide a graphical view of the entire system. After the completion
of the analysis, it is expected that the understandability of the project may improve significantly. Here,
we may also use the interaction with the customer to clarify points of confusion and to understand
which requirements are more important than others.
Data Flow Diagrams
A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within a
system. A neat and clear DFD can depict the right amount of the system requirement graphically. It can
be manual, automated, or a combination of both.
It shows how data enters and leaves the system, what changes the information, and where data is
stored.
The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be used as
a communication tool between a system analyst and any person who plays a part in the order that acts
as a starting point for redesigning a system. The DFD is also called as a data flow graph or bubble chart.
Data Dictionaries
A data dictionary is a file or a set of files that includes a database's metadata. The data dictionary hold
records about other objects in the database, such as data ownership, data relationships to other objects,
and other data. The data dictionary is an essential component of any relational database. Ironically,
because of its importance, it is invisible to most database users. Typically, only database administrators
interact with the data dictionary.
Entity-Relationship Diagrams
ER-modeling is a data modeling method used in software engineering to produce a conceptual data
model of an information system. Diagrams created using this ER-modeling method are called Entity-
Relationship Diagrams or ER diagrams or ERDs.
Components of an ER Diagrams
1. Entity
An entity can be a real-world object, either animate or inanimate, that can be merely identifiable. An
entity is denoted as a rectangle in an ER diagram. For example, in a school database, students, teachers,
classes, and courses offered can be treated as entities. All these entities have some attributes or
properties that give them their identity.
Entity Set
An entity set is a collection of related types of entities. An entity set may include entities with attribute
sharing similar values. For example, a Student set may contain all the students of a school; likewise, a
Teacher set may include all the teachers of a school from all faculties. Entity set need not be disjoint.
2. Attributes
Entities are denoted utilizing their properties, known as attributes. All attributes have values. For
example, a student entity may have name, class, and age as attributes.
There exists a domain or range of values that can be assigned to attributes. For example, a student's
name cannot be a numeric value. It has to be alphabetic. A student's age cannot be negative, etc.
There are four types of Attributes:
1. Key attribute
2. Composite attribute
3. Single-valued attribute
4. Multi-valued attribute
5. Derived attribute
1. Key attribute: Key is an attribute or collection of attributes that uniquely identifies an entity among
the entity set. For example, the roll_number of a student makes him identifiable among students.
There are mainly three types of keys:
1. Super key: A set of attributes that collectively identifies an entity in the entity set.
2. Candidate key: A minimal super key is known as a candidate key. An entity set may have more than one
candidate key.
3. Primary key: A primary key is one of the candidate keys chosen by the database designer to uniquely
identify the entity set.
2. Composite attribute: An attribute that is a combination of other attributes is called a composite
attribute. For example, In student entity, the student address is a composite attribute as an address is
composed of other characteristics such as pin code, state, country.
3. Single-valued attribute: Single-valued attribute contain a single value. For example,
Social_Security_Number.
4. Multi-valued Attribute: If an attribute can have more than one value, it is known as a multi-valued
attribute. Multi-valued attributes are depicted by the double ellipse. For example, a person can have
more than one phone number, email-address, etc.
5. Derived attribute: Derived attributes are the attribute that does not exist in the physical database,
but their values are derived from other attributes present in the database. For example, age can be
derived from date_of_birth. In the ER diagram, Derived attributes are depicted by the dashed ellipse.
3. Relationships
The association among entities is known as relationship. Relationships are represented by the diamond-
shaped box. For example, an employee works_at a department, a student enrolls in a course. Here,
Works_at and Enrolls are called relationships.
Relationship set
A set of relationships of a similar type is known as a relationship set. Like entities, a relationship too
can have attributes. These attributes are called descriptive attributes.
Degree of a relationship set
The number of participating entities in a relationship describes the degree of the relationship. The three
most common relationships in E-R models are:
1. Unary (degree1)
2. Binary (degree2)
3. Ternary (degree3)
1. Unary relationship: This is also called recursive relationships. It is a relationship between the instances of one
entity type. For example, one person is married to only one person.
2. Binary relationship: It is a relationship between the instances of two entity types. For example, the Teacher
teaches the subject.
3. Ternary relationship: It is a relationship amongst instances of three entity types. In fig, the relationships "may
have" provide the association of three entities, i.e., TEACHER, STUDENT, and SUBJECT. All three entities are many-
to-many participants. There may be one or many participants in a ternary relationship.
Cardinality
Cardinality describes the number of entities in one entity set, which can be associated with the number
of entities of other sets via relationship set.
Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at most one entity of entity set B
and vice versa. Let us assume that each student has only one student ID, and each student ID is assigned
to only one person. So, the relationship will be one to one.
2. One to many: When a single instance of an entity is associated with more than one instances of
another entity then it is called one to many relationships. For example, a client can place many orders;
a order cannot be placed by many customers.
3. Many to One: More than one entity from entity set A can be associated with at most one entity of
entity set B, however an entity from entity set B can be associated with more than one entity from entity
set A. For example - many students can study in a single college, but a student cannot study in many
colleges at the same time.
4. Many to Many: One entity from A can be associated with more than one entity from B and vice-
versa. For example, the student can be assigned to many projects, and a project can be assigned to
many students.
Traceability Matrix:
Traceability is a software engineering term that refers to documented links between software engineering
work products (e.g., requirements and test cases).
A traceability matrix allows a requirements engineer to represent the relationship between requirements and other
software engineering work products
PERSONAS, SCENARIOS, USER STORIES, FEATURE IDENTIFICATION
1. Personas are ‘imagined users’ where you create a character portrait of a type of user that you think might use
your product.
For example, if your product is aimed at managing appointments for dentists, you might create a dentist persona, a
receptionist persona and a patient persona.
2. Scenarios
A scenario is a narrative that describes how a user, or a group of users, might use your system.
There is no need to include everything in a scenario – the scenario isn’t a system specification
It is simply a description of a situation where a user is using your product’s features to do something that they want to
do.
3. User Stories
User stories are finer-grain narratives that set out in a more detailed and structured way a single thing that a user wants
from a software system.
An important use of user stories is in planning.
Many users of the Scrum method represent the product backlog as a set of user stories.
User stories should focus on a clearly defined system feature or aspect of a feature that can be implemented within a
single sprint.
4. Feature Identification
Your aim in the initial stage of product design should be to create a list of features that define your product.
A feature is a way of allowing users to access and use your product’s functionality so the feature list defines the overall
functionality of the system.
DESIGN CONCEPTS
Software design sits at the technical kernel of software engineering and is applied regardless of the software process
model that is used
Data/Class Design → transforms class models into design class realizations and the requisite data structures required to
implement the software. The objects and relationships provide the basis for the data design activity.
Architectural Design → defines the relationship between major structural elements of the software, the architectural
styles and patterns that can be used to achieve the requirements defined for the system, and the constraints that affect
the way in which architecture can be implemented. The architectural design representation—the framework of a
computer-based system—is derived from the requirements model.
Interface Design → describes how the software communicates with systems that interoperate with it, and with humans
who use it. An interface implies a flow of information (e.g., data and/or control) and a specific type of behavior.
Therefore, usage scenarios and behavioral models provide much of the information required for interface design.
Component-Level Design → transforms structural elements of the software architecture into a procedural description of
software components. Information obtained from the class-based models and behavioral models serve as the basis for
component design.
Design Process
Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the
software
Initially, the blueprint depicts a holistic view of software. That is, the design is represented at a high level of abstraction—
a level that can be directly traced to the specific system objective and more detailed data, functional, and behavioral
requirements.
As design iterations occur, subsequent refinement leads to design representations at much lower levels of abstraction.
Design Concepts
1. Abstraction: When you consider a modular solution to any problem, many levels of abstraction can be posed. At
the highest level of abstraction, a solution is stated in broad terms using the language of the problem
environment. At lower levels of abstraction, a more detailed description of the solution is provided. Problem-
oriented terminology is coupled with implementation-oriented terminology in an effort to state a solution.
Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented.
A procedural abstraction refers to a sequence of instructions that have a specific and limited function. A data
abstraction is a named collection of data that describes a data object.
2. Architecture: Software architecture alludes to “the overall structure of the software and the ways in which that
structure provides conceptual integrity for a system.
3. Patterns: a design pattern describes a design structure that solves a particular design problem within a specific
context and amid “forces” that may have an impact on the manner in which the pattern is applied and used.
4. Separation of Concerns: Separation of concerns is a design concept that suggests that any complex problem can
be more easily handled if it is subdivided into pieces that can each be solved and/or optimized independently.
A concern is a feature or behavior that is specified as part of the requirements model for the software. By
separating concerns into smaller, and therefore more manageable pieces, a problem takes less effort and time to
solve.
5. Modularity: Modularity is the most common manifestation of separation of concerns. Software is divided into
separately named and addressable components, sometimes called modules, that are integrated to satisfy
problem requirements.
6. Information Hiding: The principle of information hiding suggests that modules be “characterized by design
decisions that (each) hides from all others.” In other words, modules should be specified and designed so that
information (algorithms and data) contained within a module is inaccessible to other modules that have no need
for such information.
7. Functional Independence: Functional independence is achieved by developing modules with “ single - minded”
function and an “aversion” to excessive interaction with other modules. Stated another way, you should design
software so that each module addresses a specific subset of requirements and has a simple interface when
viewed from other parts of the program structure
8. Refinement: Refinement is actually a process of elaboration. You begin with a statement of function (or
description of information) that is defi ned at a high level of abstraction. That is, the statement describes
function or information conceptually but provides no indication of the internal workings of the function or the
internal structure of the information. You then elaborate on the original statement, providing more and more
detail as each successive refinement (elaboration) occurs.
9. Aspects: An aspect is a representation of cross cutting.
10. Refactoring: refactoring is a reorganization technique that simplifies the design (or code) of a component
without changing its function or behavior. Fowler defines refactoring in the following manner: “Refactoring is the
process of changing a software system in such a way that it does not alter the external behavior of the code
[design] yet improves its internal structure.”
THE DESIGN MODEL
The design model can be viewed in two different dimensions as illustrated in Figure 12.4 . The process dimension
indicates the evolution of the design model as design tasks are executed as part of the software process. The abstraction
dimension represents the level of detail as each element of the analysis model is transformed into a design equivalent
and then refi ned iteratively
Data Design Elements
Like other software engineering activities, data design (sometimes referred to as data architecting ) creates a model of
data and/or information that is represented at a high level of abstraction (the customer/user’s view of data). This data
model is then refi ned into progressively more implementation-specific representations that can be processed by the
computer-based system. In many software applications, the architecture of the data will have a profound influence on
the architecture of the software that must process it
Architectural Design Elements
The architectural design for software is the equivalent to the floor plan of a house. The architectural model is derived
from three sources: (1) information about the application domain for the software to be built; (2) specifi c requirements
model elements such as use cases or analysis classes, their relationships and collaborations for the problem at hand; and
(3) the availability of architectural styles
Interface Design Elements
The interface design for software is analogous to a set of detailed drawings (and specifications) for the doors, windows,
and external utilities of a house. The interface design elements for software depict information flows into and out of a
system and how it is communicated among the components defi ned as part of the architecture. There are three
important elements of interface design: (1) the user interface (UI), (2) external interfaces to other systems, devices,
networks, or other producers or consumers of information, and (3) internal interfaces between various design
components.
Component-Level Design Elements
The component-level design for software is the equivalent to a set of detailed drawings (and specifications) for each
room in a house. The component-level design for software fully describes the internal detail of each software
component. To accomplish this, the component-level design defines data structures for all local data objects and
algorithmic detail for all processing that occurs within a component and an interface that allows access to all component
operations (behaviors).
Deployment-Level Design Elements
Deployment-level design elements indicate how software functionality and subsystems will be allocated within the
physical computing environment that will support the software
SOFTWARE ARCHITECTURE
The software architecture of a program or computing system is the structure or structures of the system, which
comprise software components, the externally visible properties of those components, and the relationships among
them.
The architecture is not the operational software. Rather, it is a representation that enables you to (1) analyze the
effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when
making design changes is still relatively easy, and (3) reduce the risks associated with the construction of the software.
Architectural Styles
An architectural style is a transformation that is imposed on the design of an entire system. The intent is to establish a
structure for all components of the system. In the case where an existing architecture is to be reengineered the
imposition of an architectural style will result in fundamental changes to the structure of the software including a
reassignment of the functionality of components
Architectural Consideration
Economy —Many software architectures suffer from unnecessary complexity driven by the inclusion of unnecessary
features or non functional requirements (e.g., reusability when it serves no purpose). The best software is uncluttered
and relies on abstraction to reduce unnecessary detail.
Visibility —As the design model is created, architectural decisions and the reasons for them should be obvious to
software engineers who examine the model at a later time. Poor visibility arises when important design and domain
concepts are poorly communicated to those who must complete the design and implement the system.
Spacing— Separation of concerns in a design without introducing hidden dependencies is a desirable design concept
that is sometimes referred to as spacing. Sufficient spacing leads to modular designs, but too much spacing leads to
fragmentation and loss of visibility. Methods like domain-driven design can help to identify what to separate in a design
and what to treat as a coherent unit
Symmetry —Architectural symmetry implies that a system is consistent and balanced in its attributes. Symmetric
designs are easier to understand, comprehend, and communicate.
Emergence —Emergent, self-organized behavior and control are often the key to creating scalable, efficient, and
economic software architectures.
COMOPONENT LEVEL DESIGN
A component is a modular building block for computer software. More formally the component is defined as “a modular,
deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.”