Software Requirement Specification
Software Requirement Specification
Student’s Name
Name of Institution
Date of submission
System’s Attribute and their Definitions
The following is a table of attributes and their functions for cards in methodologies and application domain issues
Quality Attribute Definition
Performance A system’s ability to respond to functions
Usability A system’s ability to be utilized effectively
Reusability A system’s ability to be used more than once and maintain functionality
Reliability A system’s ability to be used over a long time to come
Testability A system’s ability to be facilitate its performance
Supportability A system’s ability to be maintained in an operational manner
Flexibility A system’s ability to be modified to specific designs
Security A system’s ability to deny service to unauthorized users
Maintainability A system’s ability to undergo changes and maintain it’s performance
Agility A system’s ability to rapidly undergo change
Scalability A system’s ability to support, maintain, and increase system demand
Interoperability A system’s ability to exchange data with other systems
Software interface description:
The objects that are in use in a software interface are;
Service Interface – the function of this object is to make definitions on the set of functions that are provided. These functions can be the ones used by an application or the ones provided for by the application and can have either one or more operations.
Message Type – this object is meant to define a message’s root element and then refer to the type of data.
Data Type – this object is meant to define the structure of the data.
External Definition – this object is meant to define the structure of data that the ES Repository imports.
Imported Object – this object is the IDoc or the RFC that is imported into the ES Repository.
Context Object – this object is meant to abbreviate XPath expressions and address the specificity of payload element.
The graphical representation of software interface objects is as shown below
Service Interface
Operation
Context Object
Imported Object (RFC, IDoc)
Message Type (Fault)
Data Type (Enhancement)
External Definition
In a software interface, the objects are aligned with respect to the functionality and how they convey message from one object to another. In a hierarchical kind of manner, the service interface is placed at the top where it defines the functions that are to be provided by the system. Through the service interface, the operations to be performed are displayed by the server to the client. These operations can result into context objects (where the expressions and addresses are specified), imported objects (where all the information is stored within the system), and /or message type (where the data type and the response expected are displayed). The message type is then divided to display the data type (where the client’s needs are specified) and the external definition (where the expected response to the client’s needs is designed within the system).
Message Exchange between Client and Server
For communication to take place between the client and the server, the system must be able to exchange information between the two. This communication is made possible when software interface operations are taking place within the system. The operations can be synchronous or asynchronous depending on the attributes specified. In many occasions, applications used to perform functions in service interfaces are forced to ensure that communication is threaded and kept in store for future use.
The following diagram shows how a relevant synchronous communication takes place.
Service Interface (Outbound)
Service Interface (Inbound)
Message Requested
Server
Client
Operation
Message Response
Operation
For a synchronous operation to take place, the attributes specify the functions and the results expected of the operation. In this operation, the attributes make sure that there is an expected response when the client makes a request to the server. For this to happen, the programmer delegates three tasks to provide the response expected. These tasks are fault, response, and request. Through these tasks, the server then gives feedback to the client concerning the needs of the request sent.
The following is a diagram showing how a relevant asynchronous communication takes place.
Service Interface (Inbound)
Service Interface (Outbound)
Message Requested
Client
Server
Operation
Operation
For an asynchronous operation to take place, the attributes specify the functions and the results expected of the operation. In this operation, the attributes make sure that there is no expected response when the client makes a request to the server. For this to happen, the only task delegated for the system by the programmer is fault. Through this, the server does not give feedback to the client’s request.
DFD System for B&B
The following is a mail delivery system that B&B uses to deliver goods to its client. The system allows B&B clients to conduct shopping while in their homes where they place an order to the company via emails, telephone calls, or faxes. Upon receiving an order, the company delivers goods together with their invoice to the client. Once the client has received the goods and approves they are the right ones, s/he sends money for payment and receives the due receipt to complete the transaction.
Level 0 DFD showing information exchange between B&B and the client
CataloguePayment
Receipt
Order
Goods
Invoice
Delivery Note
Client
Client
B&B’s Mail Order System
It is important to note that once the server (B&B) has received an order from the client, it sends out an invoice, a catalogue, and goods requested for by the client to them. The client then responds by making payments to the company upon receiving the goods and the catalogue. Once the client has done payments, the server sends out an invoice and a receipt to complete the transaction.
B&B’s Level 1 DFD
In order to give more details of B&B’s system transactions, a level 1 DFD is implemented to do this. Level 1 DFD is used to give more illustrations on the company’s system’s function ability on the operations that take place between the client and the company.
B&B’s level 1 DFD is represented as shown below
The most important thing to note is that data flows from Level 0 DFD are included in Level 1 to complete its functionality. This level has two functions that are carried out by the company, the first function is order processing and the second is payment processing. In this, the client makes a request on the goods he wishes to buy, as such; he places his order to the company. Once the company receives the order, it processes it in the department that deals with order processing (office 1). The department then sends the goods and the delivery not to the client. The second department (office 2) that deals with payment process then sends the catalogue. This is included in the goods and delivery note sent by the order-processing department. Once the client receives these, he makes his payment to the company. This is acted upon by the second office of the company that deals with payment processing. This department then sends an invoice and a receipt to the client to complete the process. However, for this to be complete, there are three rules that must be applied to ensure that Level 1 DFD is valid. These rules are;
Rule 1 – Each function must have input and output?
Rule 2 – Each function must have all the right information to produce an output?
Rule 3 – If not, what other information is needed and from where?
When applying the ‘Rules’ the expected results are;
Rule 1: Answer YES.
Rule 2: Function 1: YES – it has all the information needed to produce an invoice.
Function 2: NO – it lacks all the information needed to produce a receipt. This calls for rule 3.
Rule 3: For function 2 to match order with payment, it relies on the order information given by the client in function 1. The system is expected to have stored this information for any further use. The DFD becomes;
Update Level 1 DFD for B&B
Note: Function 1 generates and stores data and Function 2 reads data from the storage. For a complete diagram, all rules must be applied.
In this case, when some information necessary to produce the receipt are missing, the server reads from D1 (orders file) where all the information that relate to the clients request are stored. The purpose of storing this information upon receiving it is to allow the company to use it in Function 2.
Level 2 DFD
Like in Level 1, the system in this case is made to process two functions.
Process Order for Function 1, where there is the reception of order and issuance of invoice and goods.
Process Payment for Function 2, where there is reception of payments and issuance of catalogue and receipts.
Diagrammatically, function boxes are expanded to contain every function. This displays the correctness of data flow from Level 1 to Level 2.
B&B Level 2 DFD Diagram
After receiving an order from the client, the company starts on the processing steps necessary to ensure that the client receives his goods. Several offices are responsible in ensuring that this is done right. The key things to note are the additional functioning features that allow successful transaction to take place. These are; the get order and the goods dispatch department that are separate but work as one within the company.
Once the three rules have been applied, the updated diagram for function one and two becomes:
Updated Diagrams, Level 2 DFD for Function 1 and Function2
Update Diagram for Function One
This diagram is used to illustrate how the whole transaction is conducted from the moment the client places an order to the moment the company delivers the invoice. The important thing to note are the function ability of the system to coordinate the various offices that are responsible in handling order processing with respect to the order made.
Update Diagram for Function Two
This diagram is used to illustrate how the whole transaction is conducted from the moment the client places an order to the moment the company delivers the receipt. In this, the system is able to coordinate all the responsible offices that are entrusted with the duty of payment processing.
Updated Diagram, Level 2 DFD for B&B
It is important to note that the above diagram shows how a complete Level 2 DFD Diagram looks like when Functions One and Two are merged to display the final diagram should look like. This diagram incorporates order processing steps to the moment the invoice is given to the client and the payment processing steps to the moment the receipt is given to the client. However, it should be noted that despite working separately for each function within the company, they all come up together to ensure that the invoice and the receipt are ready at their time of delivery.
