CIS 245 Lab CIS 245 Software Engineering Lab

CIS 245 Lab

CIS 245 Software Engineering Lab This lab accompanies the software engineering course to support the content in the course. The overall goals of this lab are to introduce examples of CASE tools that are used in the different software development stages. Students will learn tools from requirement, design and testing stages. Programming tools and skills will not be introduced in this lab as they are expected to have a separate lab

Lab Objectives The objective of the lab is to provide students with the opportunity to: Apply software engineering processes and knowledge learned in theoretical course in an actual project. Interact with some CASE tools to learn them and understand how they can help the development process in the different phases. Work in teams. Understand the different roles that can be played in a team, deal with team conflicts and work together toward a successful project.

Software applications Used: Step 1 : Software Requirement specification[ Rational Requisite Pro ] Step 2 : Software Design [Rational Rose 2002] Step 3 : Software testing [ Using NUnit]

Student’s assessment Grading Policy Lab Assignment + Quizzes 25% First Exam 15% Second Exam 15% Attendance 5% Final Exam 40%

Step 1 Rational Requisite. Pro

What is “Rational Requisitepro” ? ? 1. 2. Rational Requisitepro is a Rational Requirements Management Tool. Rational Requisitepro describes the components of the software. You will have an opportunity: To use some of the templates provided with this program to document a project, as packages, queries, and documents. . Or you can attach these project documents with other rational tools as UML, RUP…

Why Using “Rational Requisit. Pro”? Requisite. Pro is used for managing requirements which is the most significant factor in delivering projects on time, on budget, and on target. Requisite. Pro helps projects succeed by giving teams the ability to manage all project requirements comprehensively and facilitating team collaboration and communication. Requisite. Pro enables you to organize, prioritize, trace relationships, and easily track changes to your requirements, The program’s unique architecture and dynamic links make it possible for you to move easily between the requirements in the database and their presentation in Word documents.

Key Concepts in Requisite. Pro The main concept is “Requirements” Project Views use standard query techniques on the database of requirements to show information and relationships. Each view is composed of the query that generates the information to be displayed and the view type There are four predetermined formats for viewing the information as follows ◦ ◦ Traceability Matrix Traceability Tree (Traced into) Traceability Tree (Traced out of) Attribute Matrix Relationships Documents

The Project In Rational Requisite. Pro, the concept of a project is used to provide the groundwork for organizing and effectively managing requirements. Each project includes the following: a database, documents, packages, document types, requirement types, attributes, attribute values, discussions, traceability relationships, saved personal and project-wide views. Only one project can be opened at a time. Numerous requirements documents can belong to a project; that means different users can edit different documents simultaneously.

Project Templates 1. 2. 3. Several project templates are shipped with Requisite. Pro Examples Use-Case Template: Use cases are particularly applicable to object-oriented software design using the Unified Modeling Language and for applications that are user-intensive. Traditional Template: This template includes a traditional Software Requirements Specification outline rather than use cases. Composite Template.

How to start using “Rational Requisite. Pro”? Program > Rational Software > Rational Requisite. Pro > Use Case Template To create new project…

Creating a new project Select traditional template and click OK. The Project Properties window opens as shown in the figure bellow. Software Requirement Specification and Rational Requisite. Pro 16

Creating a new project Enter the name of the project, select a directory, select a database, and optionally provide a description. Use the built-in Microsoft Access database. This is also the location where you would select a suitable SQL Server or Oracle solution. Click Properties to define the login and database identities. Software Requirement Specification and Rational Requisite. Pro 17

Project packages The packages within a Requisite. Pro project are used to organize the different components in the project. Packages can contain one or more of information: ◦ Requirements: the main data type in the project. ◦ Documents: based on a template, a bare document or the requirements list. ◦ Views: views, based on separate queries, of the list of requirements. For example, in the traditional project template there are three packages used to record different requirement information: ◦ Software requirements: the final list of requirements that are used for the project. ◦ Features and vision: the list of features for the project. ◦ Stakeholder requests: the list of requests for features from stakeholders. Software Requirement Specification and Rational Requisite. Pro 18

Packages Once the project template has been copied into your new document, a window similar to the one shown in the figure below appears. Software Requirement Specification and Rational Requisite. Pro 19

Requisite. Pro explorer window The figure below shows a document with the software requirements section expanded. Software Requirement Specification and Rational Requisite. Pro 20

Creating requirements within Requisite. Pro Start by building a list of requirements. The steps below show you how to add the first requirement to the project. To create the first requirement: ◦ Right-click within the tree and select New > Requirement, or select the same menu option from the main File menu. A window like the next figure opens. Software Requirement Specification and Rational Requisite. Pro 21

Requirement properties All requirements are recorded within a folder. This can either be the root folder (not generally recommended) or one of the packages. Because you are creating basic software requirements at this stage, click Browse and select the Software Requirements folder. Software Requirement Specification and Rational Requisite. Pro 22

Creating requirements within Requisite. Pro (cont…) ◦ Specify the requirement type. This is a notional marker that highlights the requirement as a specific type but has no bearing on where the requirement is stored. The type affects on what attributes are stored with the attribute and ultimately that information is used in queries and views to link and trace the sequence and source of information through the system. For the purposes of this walk through, use the Software Requirement type. ◦ Give the requirement a name. This should be enough to identify the item within the system. “The user should have the ability to enter a Username into the database into this field. ” Software Requirement Specification and Rational Requisite. Pro 23

The final list of requirements The list should look like the one shown in the figure bellow. Software Requirement Specification and Rational Requisite. Pro 24

Working with Document Types 1. 2. 3. 4. 5. 6. A Document Type is a document structure; based on document outlines. The common Document Types are: Vision. This document gives the overall view of the system. Glossary. It is important that all stakeholders use consistent terms to express requirements. Test Plan. This document describes the target-of-test (components, application, system) and its goals; the stages of testing; and the types of testing that will be addressed by this plan. If you have installed Rational Test. Manager Requirements Management Plan. This document sets out guidelines for establishing the requirements documents, types, attributes, and traceability in order to manage the project requirements. Use-Case Specification. Use cases serve as a format to express functional requirements in sequence. Use cases are especially good at documenting functional software requirements. Supplementary Requirement Specification. This document captures any requirements that cannot be tied directly to any specific use case, and especially many of the nonfunctional requirements and design constraints.

Adding further requirements Repeat this sequence with the remaining requirements from the list, as outlined in this table. All the requirements should be stored within the same Software Requirements folder and all should be of the Software Requirement type. Name Text Recipe data A recipe consists of the recipe name, a number of servings, a subtitle/description, a list of ingredients and a list of methods. Recipe search The user should be able to search for a recipe by name, description or ingredients. Recipe scaling The user should be able to change the number of servings for a recipe and have the ingredient quantities re-calculated. Software Requirement Specification and Rational Requisite. Pro 26

Adding further requirements You can see from the previous figure that each requirement is given a unique reference number. These numbers are used to help track and trace requirements through the system. Software Requirement Specification and Rational Requisite. Pro 27

Alternative requirement types The project template you are using includes a number of pre-defined requirement types: ◦ Requirement types define the attributes and other information that is stored with a requirement in the database. ◦ Requirement types are configured on a project-by-project basis or within a project template. Software Requirement Specification and Rational Requisite. Pro 28

Add or change requirement type: Project properties To add or change the type definitions: ◦ Open the properties for the project either by right-clicking on the project and choosing Properties or by double-clicking on the root project. A project properties window appears like the one shown in the figure bellow. Software Requirement Specification and Rational Requisite. Pro 29

Add or change requirement type: Requirement types tab ◦ Click the Requirement Types tab. Software Requirement Specification and Rational Requisite. Pro 30

Add or change requirement type: The requirement types tab ◦ To add a new type, click the Add or edit an existing type. You can see from the previous figure that a Developer Requirement type has been added. The basic properties for this type are shown in the figure below. Software Requirement Specification and Rational Requisite. Pro 31

Add or change requirement type: alternative requirement types ◦ Duplicate the information in the previous window to create the Developer Requirement type. The color and style are used when viewing the requirements in reports and documents so you can use this to help identify the type. Software Requirement Specification and Rational Requisite. Pro 32

Requirement attributes Flowing is a list of the attributes defined within the project for the Software Requirement: ◦ Priority: High, Medium or Low. ◦ Type: the type of requirement (usability, performance, etc). ◦ Status: whether the requirement has been approved or incorporated into the project. ◦ Difficulty: a rough guide to the difficulty that would be experienced to achieve the requirement. ◦ Stability: a guide to the stability of the requirement within an active project. Software Requirement Specification and Rational Requisite. Pro 33

Requirement attributes (cont…) ◦ Risk: a guide to the risk associated with implementing the project. For example, there might be a high developmental risk if the requirement would require changes to other parts of the system (thereby reducing stability). ◦ Enhancement Request: the information sourced from a Rational project if this Requisite. Pro project is part of a Rational project. ◦ Defect: generated by a Rational project during defect management/testing. ◦ Contact Name: for the source of the requirement. ◦ Obsolete: an indication of whether the requirement is obsolete. Software Requirement Specification and Rational Requisite. Pro 34

Specifying the attributes for a requirement type Add a development team field to the Developer Requirement type: ◦ Open the project properties. ◦ Change to the Attributes tab (shown in the figure in the next slide) and then select the Developer Requirement type from the window. A list of the attributes currently defined for the type will shown. Software Requirement Specification and Rational Requisite. Pro 35

Specifying the attributes for a requirement type Software Requirement Specification and Rational Requisite. Pro 36

Adding an attribute to a requirement type ◦ Click Add. Attributes have a label (the field name you'll populate when you create a requirement), a type, and an optional list of values that are used within a popup or list. The type is a field type just as in a database and can be an integer, floating point, text string, date, time, URL or a list, either single or multiple selection. Select the List (Single Value). Populate the list using the information shown in the figure in the next slide. Use Return to separate the values. Software Requirement Specification and Rational Requisite. Pro 37

Adding an attribute to a requirement type Software Requirement Specification and Rational Requisite. Pro 38

Creating requirement documents If you select to generate the requirements in Word, it is probably a good idea to generate and record all requirements directly within Word, although it's certainly not a requirement. To generate requirements from within a Word document: ◦ Generate a new document, or open an existing document if one was created as part of an existing project template. ◦ To create a new document, select File > New > Document or right-click on the tree view of the project and select the same options. A window opens as shown in the figure in the next slide. Software Requirement Specification and Rational Requisite. Pro 39

Document properties window Software Requirement Specification and Rational Requisite. Pro 40

Creating requirement documents ◦ Enter a name for the document (as it appears in the project) and provide a description of what the document contains. You'll be using a document for your Developer Requirements specification so name the document accordingly. As you can see from the sample, this document was created in a new package that has not been created yet, so create it in the root package. ◦ For the document type, select the Software Requirements specification. This creates a document using the corresponding Word template. ◦ Click OK to create the document and open the template within Word. Software Requirement Specification and Rational Requisite. Pro 41

Populating the document Software Requirement Specification and Rational Requisite. Pro 42

Adding requirements from within Word A new toolbar is available within Word when you are editing a Requisite. Pro document (see the figure below). You'll need this― or the Requisite. Pro menu― as you create requirements directly in the document. Software Requirement Specification and Rational Requisite. Pro 43

Adding requirements from within Word (cont…) To create a requirement within the document: ◦ Enter the text description for the requirement directly into the Word document. Enter “The Database will hold information about the recipe, recipe ingredients and recipe method” for this example. ◦ Select the text you just typed into the document and then click New Requirement (the first square bracket ([]) button), or select New Requirement from the Requisite. Pro menu. ◦ Enter a name for the requirement, specify the requirement type, and ensure that the Package and Location information within the requirement properties are correct (see the figure in next slide). These last two properties should automatically be populated based on the location of the document you are editing. Software Requirement Specification and Rational Requisite. Pro 44

Creating a new package To create a new package to help track developer requirements in the project: ◦ Right-click in the explorer and select New > Package or select the same option from the File menu. A window opens, as shown in the figure in next slide. ◦ Give the package a name. You're creating a Developer Requirements section so enter Developer Requirements into the Name field. In the Description field, enter Requirements specified by the developer based on stakeholder and user requirements. Software Requirement Specification and Rational Requisite. Pro 45

1. 2. 3. Case Study: Classics. CD. com Web Shop System (1 ) THE SYSTEM: The Classics. CD. com Web Shop system is an application available on the World Wide Web. Classics. CD. com is intended to provide a new channel of sales for Classics. CD, to supplement the existing bricks-and-mortar retail operation. THE PRODUCT: Classics. CD system wants to integrate its Web shop with the corporation’s order processing and fulfilment system. We envision a smaller scale supply-chain management system that integrates the Web application with all the stores, suppliers, and warehouses. This includes the following: A Home Shopping e-commerce system A warehouse system An order processing system

Case Study: Modify the Vision Document (2 ) Go to: Features and Vision > vision document file Add: The descriptive part of the system, problem domain, vision and objectives, and users description. Note: You can add some Requirements in this part as system or product features, organizational standards and environmental conditions. Some Examples of these Requirements

The Use-Case A Use-Case is a sequence of actions or events which a system performs that yields an observable result of value to a particular actor. A Use-Case documents Functional Requirements from the perspective of the user. Each Use-Case is described by its Flow (flow of events); the Basic flow and/or Alternative flows. Each Use-Case has its own special requirements, preconditions and/or postconditions. Any Use-Case could be extended to other Use-Cases by the extension point.

Case Study: Modifying the Use-Cases Package 1. 2. 3. 4. (3 ) In this case study there are (4) Use-Cases each of them has its own package which contains the Use. Case specification document, the events of basic and alternative flows, special requirements, and all conditions. These Use-Cases are: Arrange Shipment Check Order Status Purchase CD Shop for CD

Case Study: (3…) Modify The Use-Case “Arrange Shipment” Document Name: Arrange Shipment. Description: In this use case the system interacts with the Warehouse System to ship an item that has been purchased by a Shopper. Flow of Events: Basic Flow: i. BEGIN ii. SEND ORDER TO WAREHOUSE SYSTEM iii. WAREHOUSE SYSTEM RESPONDS

Case Study: (3…) Continue… Modify The Use-Case “Arrange Shipment” Document Alternative Flows: i. INVENTORY NOT AVAILABLE ii. INVALID INFORMATION iii. NO RESPONSE Pre. Condition: ORDER PLACED Post. Condition: SUCCESS

What is the Requirement? A requirement describes a condition or capability that a system must provide. Requirements contain a name and text, and they can be qualified with attributes to provide specific details. Note: Attributes describe a requirement in terms of user-defined characteristics or properties, such as cost, priority, and status. Requirements is either derived directly from user needs, or is stated in a contract, standard, specification, or other formally imposed document. All requirements information is stored in the database. After a requirement has been created, it can be modified, moved, and copied within the project and traced to and from other requirements in the same project or across projects.

Types of Requirements as follows: 1. 2. 3. 4. 5. Functional requirements: feature sets, capabilities, and security. Usability requirements: human factors, aesthetics, consistency in the user interface, online and context-sensitive help, wizards and agents, user documentation, and training materials. Reliability requirements: frequency and severity of failure, recoverability, predictability, accuracy, mean time between failure. Performance requirements: conditions imposed on functional requirements. Supportability requirements: testability, extensibility, adaptability, maintainability, compatibility, configurability, serviceability, installability, and localizability.

Why Manage Requirements? 1. 2. Requirements management may be defined as: A systematic approach to eliciting, organizing, and documenting the requirements of a system. A process that establishes and maintains agreement between the customer and the project team on the changing requirements of a system. It is important to manage requirements because the successful projects must be delivered on time and on budget, and they must address the client's needs. And this is not a simple task, however, because requirements are likely to change in the course of a project. By organizing and tracking your requirements and managing the requirement changes, you improve your chances of completing your project on time and on budget and delivering a product that the client still wants.

How TO Add Requirements? ? 1. 2. 3. 4. Many Ways to add Requirements: In a Document. In the Explorer (the Package) In a View. (Traceability Matrix or Tree) From Tables. Note: The requirement and its attribute values are not saved to the project database until you save the document. You can use Create Requirement Button in any Ways of adding requirements.

Creating a Requirement in the Explorer 1. 2. 3. 4. Select the package in which you want the requirement to be located and click File > New > Requirement. The Requirement Properties dialog box appears. In the General tab, select the Type from the dropdown list box, and type a Name and Text. Click OK. Note: Requisite. Pro creates the new requirement in the selected package and assigns the next available tag to the requirement.

Creating a Requirement in a Document When you create a requirement in a document, Requisite. Pro performs the following operations: The selected requirement text information is bracketed with bookmarks. The following information is associated with the new requirement: 1. Requirement tag identifier. A requirement tag consists of a prefix and a number. 2. Color and style format. If the requirement type has color and style, the new requirement is formatted with these settings. 3. Requirement attributes. The new requirement is associated with the attributes established for the requirement type. Note: Attributes can be viewed in the Requirement Properties dialog box.

Requirement Properties Window

Case Study: Adding Requirements Go to “Requirements in Vision Document” Slide Create the Supplementary Package and add these Supplementary Requirements: Usability: Interface Ease of Use: 1. The system shall follow standard interface guidelines. 2. The system shall be useable by users familiar with basic English. Training: Training shall be developed for all aspects of the system. 1. 2. 3. Reliability The system shall operate in a fault tolerant manner 7 x 24. The system shall support 1, 000 concurrent users querying for CDs. The system shall support an inventory of 1, 000 CDs. (4 )

Case Study: Adding Requirements 1. 1. (4…) Performance: The response time for CD queries shall take less than 5 seconds. Supportability: Application Standards: The system shall be compliant with Internet Explorer and Netscape Navigator as stated in the Microsoft Internet Explorer and Netscape Navigator compatibility requirements documents.

The Views (The Traceability Matrix or Tree) 1. 2. 3. Rational Requisite. Pro Views use tables or outline trees to display requirements and their attributes or the traceability relationships between different requirement types. A view is an environment for analyzing and printing requirements. You can have multiple views open at one time. You can create THREE kinds of views: An Attribute Matrix view, which displays all requirements and their attributes within a specified type. A Traceability Matrix view, which displays the relationships between requirements of two types. A Traceability Tree view, which displays the chain of traceability through the project requirements. A Traceability Tree can be set up in one of two directions: traced out of requirements of a specified type or traced into requirements of a specified type.

Traceability in a View The Traceability Matrix and Traceability Tree views display traceability relationships, and the Traced-to or Traced-from attributes appear in the Attribute Matrix. A traceability relationship is displayed as suspect when you make a change to a requirement. Arrows are used to indicate direct traceability relationships in the Traceability Matrix and Traceability Tree views. If the arrow points from A to B, then the following two statements are true: A is traced to B and B is traced from A.

Traceability Property of the Requirements

The Traceability Matrix

The Traceability Tree

Case Study: Create the Traceability Matrix and Tree (5 ) After Modifying traceability properties of all requirements, Add Traceability Matrix that connect all the Requirements (Supplementary and placed in Vision document) with Use-Cases, and that show traced to and from relationships. Add Traceability Trees, to show the Traceability Relations (to and from)