Software Engineering: SRS Document, Process Model, Use Cases, and More

Software Engineering

Table of Contents
1 SRS Document...................................................................................................................2
2 Software Engineering Process Model.............................................................................2
3 Requirement Verification Method..................................................................................4
4 Context Diagram...............................................................................................................5
5 Use Cases...........................................................................................................................6
6 Use Case Description........................................................................................................7
7 Activity Diagram.............................................................................................................14
8 Sequence Diagram..........................................................................................................16
9 Class diagram..................................................................................................................17
10 User Requirements......................................................................................................19
10.1 High level user requirements..............................................................................19
10.2 Sub-system Level Requirements.........................................................................19
10.3 Segment Level Requirements.............................................................................20
10.4 Functional requirements.....................................................................................22
10.5 Non-functional requirements..............................................................................23
11 System Specification....................................................................................................24
11.1 Technical Feasibility............................................................................................24
11.2 Economic Feasibility............................................................................................25
11.3 Operational Feasibility........................................................................................26
12 Software Testing and Acceptance Criteria...............................................................27
13 Proposed Deployment Strategy..................................................................................29
References...............................................................................................................................31
1

1 SRS Document
This project aims to prepare the consolidated version of extended SAS analysis and
Design. This project is based on Assignment 1 that is restaurant in the fast food industry.
This project update the existing SRS document by discusses the software engineering
process models, requirement verification method, UML diagram like Context diagram, class
diagram, description of use case, sequence diagram, activity diagram and the Software
testing. These are will be discussed and analysed in detail.
2 Software Engineering Process Model
A software process (otherwise called software strategy) is an arrangement of related
exercises that prompts the generation of the software. Such exercises might include
software improvement right from the beginning, or, adjusting a current framework. Any
kind of software process should incorporate accompanying the following exercises [1]:
1. Software specification: Defining software’s fundamental functionalities and
obliges around them.
2. Software designing and implementation: Software must be composed and
customized.
3. Software check and approval: Software should fit within its determination and
must meet the needs of the customer.
4. Software advancement: Software will be altered for meeting the customer as
well as the market prerequisite changes.
Practically speaking incorporates sub-exercises, for example, necessities approval,
compositional outline, unit testing, and so on. There are additionally supporting exercises,
for example, design and change administration, quality affirmation, venture administration,
customer encounter. Alongside different exercises expect to enhance the above exercises
by presenting new strategies, apparatuses, following the best practice, process
institutionalization (so the assorted variety of software forms is diminished), and so on.
When we discuss a procedure, we more often than not discuss the exercises in it. Be that as
it may, a procedure additionally incorporates the procedure portrayal, which incorporates:
• Software: The results of a movement. For instance, the result of engineering plan
possibly a model for the software design.
2

• Roles: The obligations of the general population engaged with the procedure. For
instance, the undertaking director, developer, and so forth.
• Pre and post conditions: The conditions that must be valid when a movement. For
instance, the pre-state of the building configuration is the necessities have which
the customer affirms, when the post condition refers the graphical representation
the engineering will be explored.
Here, we are utilizing the proto typing software process model.
Generally, model denotes a rendition of framework or framework’s part which
instantly created for checking the needs of the customer or possibility of certain sketched
options. Similarly, model is valuable if the customer or the designer are not sure enough
about the necessities, or the proficiency, calculations, reaction time, business rules etc. For
prototyping, the whole procedure of advertisement, the customer is involved and this
improves the customer’s acceptance probability, for the final execution. When some of the
models are developed based on the longing of getting disposed, sometimes it is conceivable
to create the model as the framework that works well.
Usage of software model is possible:
For building the prerequisites, a model could be helpful with elicitation and for the approval
of framework’s needs. It enables customers to try various things with the framework, hence
it refines the necessities. It is possible to get new ideas about the needs, and explore the
territories of software’s quality and its limitations. Moreover, as the model is produced, it
could disclose the errors in the prerequisites. The determination possibly can be altered
later for reflecting the progressions. The model could complete condescend examinations
for checking the proposed plan’s possibility, in the framework [2].
The periods of a model are:
• Establish goals: The targets of the model ought to be made express from the
beginning of the procedure.
• Define model Functionless: Decides the list of information sources along with the
model’s normal outcomes. For diminishing the cost of prototyping and speeding up
the plan of conveyance, you could disregard certain Functionless. For instance,
reaction time and memory use except if they are pertinent to the model’s goal.
• Model Designing: Underlying model is produced which incorporates only the UIs.
3

• Model Evaluation: As the customers are ready for utilizing the model, they must
find the prerequisites blunders. By using the both input the determinations and
model could be improved. When the progressions will be presented, a rehash of
stage-3 and may be needed.
• Prototyping is more independent, complete the improvement procedure, yet
rather a method for dealing with the utilized regards for full techniques.
3 Requirement Verification Method
The requirement verification method are,
Confirmation by Test includes uncommon test gear and additionally instrumentation.
It additionally includes running different "tests" to gather information on the framework
that will indicate evidence the prerequisite has been met. Since there are different
arrangements of information gathered, we at that point need to dissect the information to
make an assurance regardless of whether the check achievement criteria has been met to
state the confirmation by Test was fruitful. Before running these tests we may examine the
confirmation aftereffects of the necessities to this prerequisite. For this situation, the
strategy for confirmation is Test.
Confirmation by Demonstration likewise includes running no less than one "test"
without uncommon test hardware or instrumentation to gather the arrangements of
information that we dissect to demonstrate the framework meets a necessity. Once more,
before running these tests we may assess the confirmation aftereffects of the necessities to
this prerequisite. For this situation, the technique for check is Demonstration [3].
Check by Analysis is utilized when one of alternate strategies isn't suitable or you
can't stand to utilize Verification by Test for each prerequisite or you can't complete a
conclusion to-end test yet just on parts of the framework. For this situation you gather
information on parts of the framework by means of test. At that point in light of this
information and your insight into the framework outline, you make a designing judgment
regardless of whether the characterized achievement criteria has been met keeping in mind
the end goal to reason that confirmation by Analysis was fruitful. For this situation, despite
the fact that I may have run a few tests to gather the information, the strategy for check is
Analysis.
4

Confirmation by Inspection is the point at which you can utilize one of your faculties to
demonstrate if the framework meets a prerequisite. You don't need to practice the
framework, you can watch the aftereffects of your perceptions or reviews to demonstrate
the framework meets a necessity.
4 Context Diagram
A system of the context diagram that can used for the diagram of the engineering
explains the limitations among the systems, system parts, entities and its environment’s
representation, which allows interaction. The system of the diagram that can use for the
high levels view of the context diagram. It is similar to a block diagram. The external entities’
system context diagrams can represent the system interaction. Such system that can used of
the requirement functional specification. The context diagram that used for the picture and
the data center with hardly any details about the individual structure surrounding all its
interacting systems, and the environmental activities. The system context diagram’s
objective refers to concentrate on the events and the external factors which must be
considered for the development of a whole set of system prerequisites and limitations of
the diagram.
The Content Diagram is represented as follows.
5

In context diagram, the customer should be able to register to create an account in the
information system. The customer able to login into their account. Once customer login
successfully, make an order. A customer or staff should be able to view orders to track the
status of the pending order for example getting the remaining waiting time. A staff updates
the status of the order to either ready when the order is ready for pickup and complete
when the order is has been picked up by the customer. A staff adds payment for an order
when the customer comes to pick up the order. Update or delete an order, Delete a
customer record from the system, an admin adds, updates or deletes a branch and an
admin adds a staff member to a certain branch. Finally, admin generate the report for the
order [4].
5 Use Cases
Use case diagram refers to a representation which is easy to understand for showing
the user's interaction with the system that shows the relationship between the user and the
different use cases in which there is involvement of the user. This diagram describes the
actions in terms of the behaviour diagrams where certain system or the subject must or
could perform the actions based on collaboration with a single or multiple external system
users or called as the actors. The use case diagram’s primary objective includes, showing the
interactions with your system, and shows the major goals which the system achieves with
them. The stakeholder is referred as the primary actor of the use case diagram, who is called
on the system for delivering its services. The use case analysis denotes to a method which is
utilized for identifying the system requirements that are linked with the software or the
process design. The information is utilized for both defining the utilized processes as well as
defining the classes. The classes are the collection of actors and processes that are utilized
in both in the use case diagram and the complete overall use case diagram. For
demonstrating various methods for the user to interact with the system, the use case
analysis diagram in UML for is used.
The section provides the details of the identified use cases.
Requirement Description
Customer registration The customer should be able to register to create an account in the
6

information system
Customer login The customer should be able to login into their account
Make order A customer should be able to make an order
View order A customer or staff should be able to view orders to track the
status of the pending order for example getting the remaining
waiting time
Staff login A staff logins
Process order A customer process an order made by a customer. Processing an
order means accepting the order so that the order can be prepared
and packaged. When the order is ready the status of the order is
updated to ready for customer pickup.
Update order status A staff updates the status of the order to either ready when the
order is ready for pickup and complete when the order is has been
picked up by the customer
Add payment A staff adds payment for an order when the customer comes to
pick up the order
Manage order Update or delete an order
Manage customer Delete a customer record from the system
Manage branch An admin adds, updates or deletes a branch
Add staff An admin adds a staff member to a certain branch
Generate Generate reports for orders. Report can be a daily or monthly
report
6 Use Case Description
Use case Description of overall system is shown below.
Requirement Actor Description Inputs Outputs
Customer
registration
Customer The customer
should be able
to register to
create an
Customer
details; First
name, last
name, email,
Success: if the
registration is
successful
Fail; if the
7