 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

The objective of the lab is to provide students with the opportunity to:  Apply software engineering processes and knowledge learned in the 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.

 Step1 : Software Requirement specification[ Rational Requisite Pro ]  Step2 : Software Design [Rational Rose 2002]  Step3 : Software testing [ Using NUnit]

 Grading Policy  Lab Assignment + Quizzes25%  First Exam 15%  Second Exam 15%  Attendance 5%  Final Exam 40% 

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

 RequisitePro is used for managing requirements which is the most significant factor in delivering projects on time, on budget, and on target.  RequisitePro helps projects succeed by giving teams the ability to manage all project requirements comprehensively and facilitating team collaboration and communication.  RequisitePro 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.

 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

 In Rational RequisitePro, 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, requirements, 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.

 Several project templates are shipped with RequisitePro  Examples 1. 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. 2. Traditional Template: This template includes a traditional Software Requirements Specification outline rather than use cases. 3. Composite Template.

Program > Rational Software > Rational RequisitePro > Use Case Template To create new project…

Software Requirement Specification and Rational RequisitePro 16  Select traditional template and click OK. The Project Properties window opens as shown in the figure bellow.

Software Requirement Specification and Rational RequisitePro 17  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 RequisitePro 18  The packages within a RequisitePro 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 RequisitePro 19  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 RequisitePro 20  The figure below shows a document with the software requirements section expanded.

Software Requirement Specification and Rational RequisitePro 21  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 RequisitePro 22  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 RequisitePro 23 ◦ 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 RequisitePro 24  The list should look like the one shown in the figure bellow.

 A Document Type is a document structure; based on document outlines.  The common Document Types are: 1. Vision. This document gives the overall view of the system. 2. Glossary. It is important that all stakeholders use consistent terms to express requirements. 3. 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 TestManager 4. Requirements Management Plan. This document sets out guidelines for establishing the requirements documents, types, attributes, and traceability in order to manage the project requirements. 5. 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. 6. 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.

Software Requirement Specification and Rational RequisitePro 26  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. NameText 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 RequisitePro 27  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 RequisitePro 28  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 RequisitePro 29  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 RequisitePro 30 ◦ Click the Requirement Types tab.

Software Requirement Specification and Rational RequisitePro 31 ◦ 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 RequisitePro 32 ◦ 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 RequisitePro 33  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 RequisitePro 34 ◦ 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 RequisitePro 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 RequisitePro 35  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 RequisitePro 36

Software Requirement Specification and Rational RequisitePro 37 ◦ 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 RequisitePro 38

Software Requirement Specification and Rational RequisitePro 39  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 RequisitePro 40

Software Requirement Specification and Rational RequisitePro 41 ◦ 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 RequisitePro 42

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

Software Requirement Specification and Rational RequisitePro 44  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 RequisitePro 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 RequisitePro 45  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.

 THE SYSTEM: The ClassicsCD.com Web Shop system is an application available on the World Wide Web. ClassicsCD.com is intended to provide a new channel of sales for ClassicsCD, to supplement the existing bricks-and-mortar retail operation.  THE PRODUCT: ClassicsCD 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: 1. A Home Shopping e-commerce system 2. A warehouse system 3. An order processing system (1)(1)

 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. (2)(2) Some Examples of these Requirements

 ClassicsCD.com Web Shop system features: 1. Secure payment method. 2. Easy browsing for available titles. 3. Ability to search for CDs by multiple criteria. 4. Ability to check the status of an order.  ClassicsCD.com Administration System features: 1. Ability to add/remove CDs available for sale. 2. Ability to check on Shopper orders. 3. Maintain Shopper information.  Other Product features: 1. Standard: ClassicsCD applications must comply with common Web user interface guidelines. Case Study: Requirements in Vision Document (2…) Back to “Use-Case” slideBack to “How to Add requirement” slide

 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.

 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: 1. Arrange Shipment 2. Check Order Status 3. Purchase CD 4. Shop for CD (3)(3)

 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 (3…)

Alternative Flows: i. INVENTORY NOT AVAILABLE ii. INVALID INFORMATION iii. NO RESPONSE  PreCondition: ORDER PLACED  PostCondition: SUCCESS (3…)

 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.

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

 Requirements management may be defined as: 1. A systematic approach to eliciting, organizing, and documenting the requirements of a system. 2. 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.

 Many Ways to add Requirements: 1. In a Document. 2. In the Explorer (the Package) 3. In a View. (Traceability Matrix or Tree) 4. 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.

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

 When you create a requirement in a document, RequisitePro 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.

 Go to “Requirements in Vision Document” Slide 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.  Reliability 1. The system shall operate in a fault tolerant manner 7 x The system shall support 1,000 concurrent users querying for CDs. 3. The system shall support an inventory of 1,000,000 CDs. (4)(4)

 Performance: 1. The response time for CD queries shall take less than 5 seconds.  Supportability: 1. 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. (4…)

 Rational RequisitePro 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: 1. An Attribute Matrix view, which displays all requirements and their attributes within a specified type. 2. A Traceability Matrix view, which displays the relationships between requirements of two types. 3. 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.

 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.

 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) (5)(5)