What are Requirements?

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 RequirementsExample • 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