2. What are Requirements? Functional requirements describe a list of functions that the system must accomplish. Nonfunctional requirements describe other constraints such as performance expectations or standards to be used. This discussion centers around functional requirements. Knowing what is to be built is one of the most important aspects of a software development process. Getting the requirements in line with what the actual users need is also a very important aspect.

3. Use Cases Requirements are often based on use cases. A use case can be used to describe a systems functional requirements. A use case treats the system which is to be built as a black box. A user (Actor) does something and the system responds. The use case is not described in terms of GUI components or specific systems. Instead it is described in more generic terms as simple user actions. For example, entering data, viewing the results of a query to the database, etc..

4. How can Requirements be Described? SRS –The IEEE and many government agencies describe requirements through the use of Software Requirements Specifications (SRS). Each has a definition for the required contents. Use Cases –Requirements can be described as use cases. The two traditionally haven’t been related.

5. Use Cases and Requirements Example Actor:Auctioneer UseCase:EnterBidInformation –Requirement:InputPerson The system shall allow the Auctioneer to enter the contents of the city, name, useCreditCard associated with the Person –Requirement:ProcessCreditCard The system shall allow the Auctioneer to run the VerifyWithBank algorithm described as: Go out to the Bank server, process the credit card transaction

6. How can Requirements be Described? Cont’d Simulation –A mechanism which can be used to communicate the requirements as use cases. –The simulation shows how the user interacts with the system and how the system responds. Modeling –UML tools such as Together™ enable you to create requirements by creating use cases. They provide diagrams to chose from which you can drag and drop.

7. RequireMentor™ Tool Guides you to describe use cases for a system which you are specifying –you pick and choose forms and fill in blanks Creates simulations of use cases Relates requirements and use cases Creates SRS Creates a model class diagrams sequence, activity, use cases

9. 1. Define Actors Start by creating Actors and Job Titles Create separate types of Actors. They are distinguished by the Jobs that they do using the computer. Each Actor belongs to an organization Create all your known Actors and assign only the ‘Jobs’ for now. Job’s are optional.

10. Actors and Job Titles Attempting to answer the question: Who will be using the system and what types of activites do their jobs include?

14. 2. Create Roles For each Actor, define one or more Roles. Roles are distinct interactions that an Actor has with the computer to accomplish a meaningful unit of work Later, you will define a Use Case for each role.

17. 3.Create Use Cases Create Use Cases for each Actor, one for each of its Roles. For now, just fill out the Use Case name, select an Actor, and select one of its Roles.

20. 4. Define a Story for each use case A Story is a sequence of screens which simulate how the Actor will interact with the system. A Story has an initial Screen. Each Screen is associated with a Requirement in the form: – The system shall … Choose from a fixed collection of Screen types

22. Five Screen Types Input Data View Data View and Select from Data Input from a Device Run Processing

23. 5. Enter Info for the Screen Type Enter the Screen name Select a previously defined Data Entity (or define one on the fly Do not link Screen into a sequence by filling out Select Next screen at this time.

25. 6. Define a Data Entity A Data Entity is named and has a collection of fields Each field has a type The type may be another Data Entity

27. Add Additional Screens Create another Screen for each of the Requirements within the Story The initial screen must be so designated

30. 4. Link Screens Together Link a screen to another Screen defined for the story or to another story If you like to another Story, you can reuse it. For example, may want to always verify the user’s name and password from several different places. Link the Password Story as a next screen

32. 6. View the Documentation As an Software Requirements Spec As a running simulation in html As an XMI(eye) file which can be imported into a UML tool Can also export the project as XML(el) or just save it

40. Together™ Import XMI Open Together 6.0 Create a new Project using the Project Wizard Select File->Import->Model from XMI Class, Use Case, Sequence, and Activity Diagrams will be created

45. Guided Generation of Software Requirements RequireMentor™ was used to discover classes and methods Together™ was used to create the UML models RequireMentor™ provided guidance for –defining the contents of a use case –defining the format of requirements –generating many descriptions of the requirements