DOC

Process MeNtOR 3

By Frederick Gordon,2014-05-07 10:57
8 views 0
Process MeNtOR 3

Process MeNtOR 3.o

    Requirements Model

    Version: 1.0

    Print Date: 5/7/2010 10:58:00 AM

    Release Date:

    Release State: Initial/Core/Final

    Approval State: Draft/Approved

    Approved by:

    Prepared by:

    Reviewed by:

    Path Name:

    File Name: T3-ReqmtsModel.doc

    Document No:

     Process MeNtOR 3

    Document Change Control

    Version Date Authors Summary of Changes

Document Sign-Off

    Name (Position) Signature Date

     Page 2 of 16

    ? Copyright 1998 Object Oriented Pty Ltd Modification Date: 5/7/2010 10:58:00 AM

     Process MeNtOR 3

    Contents

    1 INTRODUCTION ........................................................................................................ 5 1.1 Purpose ........................................................................................................................... 5 1.2 Overview ........................................................................................................................ 5 1.3 References ...................................................................................................................... 5 2 BUSINESS SCENARIO MODEL ............................................................................... 6 2.1 Actors ............................................................................................................................. 6 2.1.1 Overview .................................................................................................................... 6 2.1.2 Actor Diagram ............................................................................................................ 6 2.1.3 Actor Definitions ........................................................................................................ 6 2.1.4 A-nn .................................................................................................. 7

    2.2 Use Case Descriptions .................................................................................................... 8 2.2.1 XXXX-NNNN ................................................................................ 8

    2.3 Use Case Diagrams ....................................................................................................... 10 3 DOMAIN MODEL ..................................................................................................... 11 3.1 Domain Model Class Diagram ..................................................................................... 11

    3.2 Domain Model Class Definitions ................................................................................. 11

    3.2.1 ......................................................................................... 12

    4 INTERACTION DIAGRAMS .................................................................................. 12 4.1 Sequencing Diagrams ................................................................................................... 12

    4.2 Collaboration Diagrams ................................................................................................ 12

    5 NON-FUNCTIONAL REQUIREMENTS SPECIFICATION .............................. 13 5.1 Overview ...................................................................................................................... 13 5.2 Enabling Technologies ................................................................................................. 13

    5.2.1 Target Hardware & Hardware Interfaces ................................................................. 13

    5.2.2 Target Development Environment ........................................................................... 13

    5.2.3 System Interfaces ...................................................................................................... 13 5.3 Capacity Planning ......................................................................................................... 13 5.3.1 Permanent Storage .................................................................................................... 13 5.4 Network ........................................................................................................................ 13 5.5 Workstations ................................................................................................................. 14 5.6 Operational Parameters................................................................................................. 14

    5.6.1 Useability .................................................................................................................. 14 5.6.2 Reliability ................................................................................................................. 14

     Page 3 of 16

    ? Copyright 1998 Object Oriented Pty Ltd Modification Date: 5/7/2010 10:58:00 AM

     Process MeNtOR 3

    5.6.3 Maintainability ......................................................................................................... 14 5.6.4 Portability ................................................................................................................. 14 6 ACTIVITIES PLAN ................................................................................................... 15 7 DOMAIN DICTIONARY .......................................................................................... 15 7.1 Terms and Abbreviations.............................................................................................. 15

    7.2 Notation/Formula ......................................................................................................... 16

     Page 4 of 16

    ? Copyright 1998 Object Oriented Pty Ltd Modification Date: 5/7/2010 10:58:00 AM

     Process MeNtOR 3

    1 Introduction

    1.1 Purpose

    This document details the requirements the system .

    For small projects (ie. Uni-SEP) this document may contain the complete set of

    business scenarios for the project. In larger projects this document will cover only a

    particular subject area.

    1.2 Overview

    Provide a brief overview of the problem to be solved and the requirements of the

    system. This section should be a brief executive summary.

    1.3 References

    Include references to other documents that may assist in the understanding of this

    document. (ie. Project Plan)

     Page 5 of 16

    ? Copyright 1998 Object Oriented Pty Ltd Modification Date: 5/7/2010 10:58:00 AM

     Process MeNtOR 3

    2 Business Scenario Model

    2.1 Actors

    2.1.1 Overview

    Describe in one or two paragraphs the environment in which the actors exist.

    Note that actors can be people or external systems.

    2.1.2 Actor Diagram

    Introduce the diagram by explaining it in words.

    Insert an actor inheritance diagram here that illustrates the relationships that exist

    between the various actor types. This diagram is critical when abstract actor types

    are included in the Requirements Model. An example follows:

    AuthorisedEmployee

    Order Accessor

    System Administrator

    Task OwnerOrder Administrator

2.1.3 Actor Definitions

    Repeat the section below for each actor.

    Brief description of the actor and its role in the system. This description Description

    should be no more than a small paragraph and should give the reader an

    understanding of the role of the actor in the organisation. Mandatory.

    Any other names by which this actor may be known. A simple list is Aliases

    sufficient. Say „None‟ if there are none.

    The ancestors for the actor. Some actors may be specialised types of Inherits

    other actors. A simple list of the names of the ancestors will suffice. Say

    „None‟ if there are none.

    Active/Passive - Person/External System. Mandatory. Actor Type

    Person to contact about the actor. This may be the person who Contact Person

    interviewed the actor or the user who is actually an instance of the actor.

    Mandatory.

    The contact details for the contact person. These details are recorded to Contact Details

    allow questions and follow-up to be directly appropriately. Mandatory.

     Page 6 of 16

    ? Copyright 1998 Object Oriented Pty Ltd Modification Date: 5/7/2010 10:58:00 AM

     Process MeNtOR 3

2.1.4 A-nn

     Description

     Aliases

     Inherits

     Actor Type

     Contact Person

     Contact Details

     Page 7 of 16

    ? Copyright 1998 Object Oriented Pty Ltd Modification Date: 5/7/2010 10:58:00 AM

     Process MeNtOR 3

    2.2 Use Case Descriptions

    This section documents the complete business scenarios within the scope of this

    project.

    2.2.1 XXXX-NNNN

    Insert each business scenario definition for the subject area in here.

    Description: Brief description of the business scenario and its context. This description should be

    no more than one paragraph and should give the reader an understanding of the role

    of the scenario but not the detail. Mandatory.

    Actors:

    List the actor names that perform the scenario. Ensure that their details are entered

    in an actor definition template. Mandatory.

    Preconditions: Specify any conditions that must be met before this scenario can be performed.

    These should be set out as a numbered list. The list of preconditions should be stated

    in a declarative fashion (eg. „the alarm must be on‟). This will help put the business

    scenario in context. It will also facilitate verification and the generation of test

    cases. If there are none then say „None‟.

    Scenario Text: Narrative of the scenario. The scenario narrative should be stated in concise

    sentences for each step of the scenario. Each step should be numbered (eg. 1, 2, 3)

    with sub-steps using levelled numbers (eg. 1.1, 1.2, 1.3). Levelling should not

    generally extend to more than three levels deep.

    When referencing other business scenarios, the key word uses, and the business

    scenario name following it, should be italicised. Try to begin the step with the uses

    and then explain why it is needed. For example.

    1. Use Maintain Customer to update the postal address

    2. Calculate commission fee (see note 4). Details of business rules should not be included in the text. Instead refer to a note

    for details.

    Any error messages should also be presented as part of the scenario. Any

    alternatives should be referred to as alternative n (where n is the number of the

    alternative as specified in the alternative section) and italicised in the text.

    The text should not generally extend for more than one to two pages.

    Alternative Courses:

    Narrative of alternative scenario. This section should include the prerequisite

    conditions necessary for the alternative scenario to occur. Each alternative scenario

    should be numbered sequentially (eg. 1, 2, 3) and it should be ensured that the

    alternative is used in the scenario narrative above. If there are not any then say

    „None‟. Alternative courses have a similar layout and structure as scenario text.

    Extends:

     Page 8 of 16

    ? Copyright 1998 Object Oriented Pty Ltd Modification Date: 5/7/2010 10:58:00 AM

     Process MeNtOR 3

    Include the coma delimited names of any other business scenarios that this scenario

    extends. If there are none then say „None‟.

    User Interfaces: Unique ids of the logical views used in accomplishing this scenario. If there are

    none then say „None‟. Constraints:

    Describe any constraints or requirements that will not be met or are out of scope.

    Such explicit statement avoid confusion and helps clarify any limitations implicit in

    the business scenario. These should be numbered sequentially (eg. 1, 2, 3). If there

    are none then say „None‟.

    Questions:

    State any questions that need to addressed before the business scenario can be

    considered complete. Delete the question one it has been answered within another

    part of the business scenario. The business scenario can not become final if there

    questions still in this section. Include the name of the person who is charged with

    resolving the question. If there are none then say „None‟.

    Notes:

    State any notes that relate to this business scenario. Keep them to 2 to 3 sentences.

    Do not state complex business rules here, instead just include the name of the source

    document and page or section number where they are defined. If business rules do

    not yet exist then specify the contact who will define it.

    If necessary, include any comments concerning business practices that assist in

    explaining how a particular step fits into the overall business environment.

    State any business practices that will require changing as a result of this business

    scenario.

    If there are none then say „None‟.

    Authors:

    The names and designated initials of the people who are responsible for writing this

    scenario. This will usually be a User Representative and a Requirements Modeller

    assigned to define and document this area of the requirements. Mandatory.

    Source Documents:

    List of the sources and documents from which the requirements for this specific

    scenario have been drawn.

     Page 9 of 16

    ? Copyright 1998 Object Oriented Pty Ltd Modification Date: 5/7/2010 10:58:00 AM

     Process MeNtOR 3

    2.3 Use Case Diagrams

    This section presents the business scenarios of the subject area in a graphical form.

    Assign an appropriate title to the graphical scenario model and insert the diagram

    here.

    Subject Area Name

    S001 Business<>Scenario Name

    S002 BusinessA02Scenario NameActor Name

    S003BusinessusesScenario Name

    A01Actor Name

    S004 BusinessScenario Name<>

    A03Actor NameS005 BusinessScenario Name

     Page 10 of 16

    ? Copyright 1998 Object Oriented Pty Ltd Modification Date: 5/7/2010 10:58:00 AM

Report this document

For any questions or suggestions please email
cust-service@docsford.com