Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
A comprehensive guide on software requirements specification and software engineering lab manual. It covers the use of uml diagrams, including use case diagrams, class diagrams, sequence diagrams, collaboration diagrams, activity diagrams, state diagrams, and physical diagrams. The manual explains the purpose, when to use, and how to draw each type of diagram. It also provides examples of their application in various systems such as hospital management system, atm system, online reservation system, online library management system, hotel management system, and online shopping system.
Typology: Essays (university)
1 / 57
This page cannot be seen from the preview
Don't miss anything!
01
Academic Year 2018- R16 Regulation
Associate Professor Associate Professor
PROGRAMMER
Develop the software project startup, prototype model, using software engineering methodology
▲ StarUML / UMLGraph / Topcased
Software Requirements is a field within Software Engineering that deals with establishing the needs of stakeholders that are to be solved by software. The IEEE Standard Glossary of Software Engineering Technology defines a software requirement as:
1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations 1.4. References 1.5. Overview
2. Overall description
2.1. Product perspective 2.1.1. System interfaces 2.1.2. User interfaces 2.1.3. Hardware interfaces 2.1.4. Software interfaces 2.1.5. Communications interfaces 2.1.6. Memory constraints 2.1.7. Operations 2.1.8. Site adaptation requirements 2.2. Product functions 2.3. User characteristics 2.4. Constraints 2.5. Assumptions and dependencies
2.6. Apportioning of requirements
3. Specific Requirements
3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communication interfaces 3.2 Specific requirements 3.2.1 Sequence diagrams 3.2.2 Classes for classification of specific requirements 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.5.1 Reliability 3.5.2 Availability 3.5.3 Security 3.5.4 Maintainability 3.6 Other requirements
4. Supporting information
4.1 Table of contents and index 4.2 Appendices
The following subsections of the SRS should provide an overview of the entire SRS. 1.1 Purpose Identify the purpose of this SRS and its intended audience. 1.2 Scope.
(c) Describe the computer hardware and peripheral equipment to be used (overview only) A block diagram showing the major components of the larger system or project, interconnections, and external interfaces can be very helpful.
2.2 Product Functions Provide a summary of the functions that the software will perform. Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher-level specification (if one exists) that allocates particular functions to the software product. The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time. Block diagrams showing the different functions and their relationships can be helpful. Such a diagram is not a requirement on the design of a product itself; it is simply an effective explanatory tool.
2.3 User Characteristics Describe those general characteristics of the eventual users of the product that will affect the specific requirements.
Many people interact with a system during the operation and maintenance phase of the software life cycle. Some of these people are users, operators, and maintenance and systems personnel. Certain characteristics of these people, such as educational level, experience, and technical expertise impose important constraints on the system's operating environment.
3. SRS of ATM
3.1 Purpose This document describes the software requirements and specification for an automated teller machine (ATM) network. The document is intended for the customer and the developer (designers, testers, maintainers). 3.2 Scope The network enables customers to complete simple bank account services via automated teller machi nes (ATMs) that may be located off premise and that need not be owned and operated by the custome r’s bank. The ATM identifies a customer by a cash card and password. It collects information about a simple account transaction (e.g.,deposit, withdrawal,transfer, bill payment),communicates the transa ction information to the customer’s bank, and dispenses cash to the customer. The banks provide thei r own software for their own computers 3.3 DEFINITIONS, ACRONYMS AND ABBREVATIONS Account A single account at a bank against which transactions can be applied. Accounts may be of various typ es with at least checking and savings. A customer can hold more than one account. MaxDailyWD The maximum amount of cash that a customer can withdraw from an account in a day (from 00:00 AM to 23:59 PM) via ATMs. PIN It refers to Personal Identification Number. Used to identify and validate the login of an ATM user. 3.4 REFERENCES
4. Visual modeling and Rational Rose Tool Visual modeling is the graphic representation of objects and systems of interest using
graphical languages. Visual modeling languages may be General-Purpose Modeling languages or Domain-Specific Modeling languages.
Rational Rose is an object-oriented Unified Modeling Language (UML) software design tool intended for visual modeling and component construction of enterprise-level software applications. In much the same way a theatrical director blocks out a play, a software designer uses Rational Rose to visually create (model) the framework for an application by blocking out classes with actors (stick figures), use case elements (ovals), objects (rectangles) and messages/relationships (arrows) in a sequence diagram using drag-and-drop symbols. Rational Rose documents the diagram as it is being constructed and then generates code in the designer's choice of C++, Visual Basic, Java, Oracle8, Corba or Data Definition Language.
Two popular features of Rational Rose are its ability to provide iterative development and round-trip engineering. Rational Rose allows designers to take advantage of iterative development (sometimes called evolutionary development) because the new application can be created in stages with the output of one iteration becoming the input to the next. (This is in contrast to waterfall development where the whole project is completed from start to finish before a user gets to try it out.) Then, as the developer begins to understand how the components interact and makes modifications in the design, Rational Rose can perform what is called "round-trip engineering" by going back and updating the rest of the model to ensure the code remains consistent.
5. UML INTRODUCTION
UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems.
▲ A conceptual model can be defined as a model which is made of Concepts and their relationships. ▲ A conceptual model is the first step before drawing a UML diagram. It helps to understand the entities in the real world and how they interact with each other.Conceptual model of UML can be mastered by learning. The following three major elements: ▲ UML building blocks. ▲ (^) Rules to connect the building blocks. ▲ Common mechanisms of UML.
The purpose of OO analysis and design can described as: 1.Identifying the objects of a system. 2.Identify their relationships. 3.Make a design which can be converted to executables using OO languages. OO Analysis --> OO Design --> OO implementation using OO languages. ▲ During object oriented analysis the most important purpose is to identify objects and describing them in a proper way. If these objects are identified efficiently then the next job of design iseasy. The objects should be identified with responsibilities. Responsibilities are the
Collaboration Collaboration defines interaction between elements
Use case represents a set of actions performed by a system for a specific goal.
Component describes physical part of a system.
A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things:
Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.
State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.
Grouping things can be defined as a mechanism to group elements of a UML model together. There is only one grouping thing available Package Package is the only one grouping thing available for gathering structural and behavioral things
Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements. Note is the only one Annotational thing available
A note is used to render comments, constraints etc of an UML element.
Relationships are another most important building block of UML. It shows how elements are associated with each other and this association describes the functionality of an application. There are four kinds of relationships available. ▲ Dependency ▲ Association ▲ Generalization.
State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions.
Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing.
Physical Diagrams
A use case is a set of scenarios that describing an interaction between a user and a system. A use case diagram displays the relationship among actors and use cases. The two main components of a use case diagram are use cases and actors.
An actor is represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents some action the user might perform in order to complete a task.
When to Use: Use Cases Diagrams
Use cases are used in almost every project. These are helpful in exposing requirements and planning the project. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible.
Modeling steps for Use case Diagram
How to Draw: Use Cases Diagrams
Use cases are a relatively easy UML diagram to draw, but this is a very simplified example. This example is only meant as an introduction to the UML and use cases. Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps.
These steps would generate this simple use case diagram:
Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and contents using design elements such as classes, packages and objects. Class diagrams describe three different perspectives when designing a system, conceptual, specification, and implementation. These perspectives become evident as the diagram is created and help solidify the design. This example is only meant as an introduction to the UML and class diagrams. Classes are composed of three things: a name, attributes, and operations.
Below is an example of a class.
Class diagrams also display relationships such as containment, inheritance, associations and others. Below is an example of an associative relationship:
The association relationship is the most common relationship in a class diagram. The association shows the relationship between instances of classes. For example, the class Order is associated with the class Customer. The multiplicity of the association denotes the number of objects that can participate in then relationship. For example, an Order object can be associated to only one customer, but a customer can be associated to many orders. Another common relationship in class diagrams is a eneralization. A generalization is used when two classes are similar, but have some differences.
