1 / 45

What are Requirements?

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.

Download Presentation

What are Requirements?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related