Requirements Database - Project 1 - Fall 2002 | CSE 784, Study Guides, Projects, Research of Software Engineering

Material Type: Project; Class: Software Engineering Studio; Subject: Computer Engineering; University: Syracuse University; Term: Fall 2002;

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 08/09/2009

koofers-user-wi9
koofers-user-wi9 🇺🇸

9 documents

1 / 2

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CSE784 – Software Studio Fall 2002
Project #1 – Requirements Database
B-Specification due Sep 23, code due Sep 30, C-Specification due Oct 7, revised B-Specification due
Oct 14
Purpose:
This program captures and saves customer requirements1, development
requirements2, and requirements issues. It provides capability to:
Number each customer requirement, and each development requirement.
Attach an issue statement with any requirement, above. Provide a status for each
issue which has one of the two values: open or closed.
Provide a title for each requirement.
Stamp each requirement with a creation time and date and a last modified time and
date.
Edit requirements and issues already entered.
Add new, or delete existing, requirements and issues at any time.
Associate a priority (levels High, Normal, or Low) with any requirement’s issue.
Display any requirement by number or title.
Sort requirements by number, title, creation date, last modified date, or priority.
Save and restore the database in a file3.
You may assume that the entire database can fit into memory so your design can
read the entire file contents at one time.
Requirements:
Your Requirements program:
1. Shall read from a database file at startup if one is defined. On process
termination, it shall save any entered data to the opened file4.
2. Shall save all requirements and issues at program termination, using an XML-
based format.
3. Shall accept from the user a definition of a new requirement item in one of the
two categories (1) customer specification, or (2) development specification. It
shall, for (2), require the user to select one or more customer specifications to
which it is allocated or explicitly indicate that it is a derived requirement.
4. Each item shall consist of a number, title, time-date stamps, a multi-line text
description, and priority setting. Item numbers shall consist of a letter, either A
or B, and a number. The numbers shall be generated by the program in
consecutive order for each group, A or B.
5. Shall support addition of a new requirement, modification of an existing
requirement, or addition or modification of multi-line issue text, associated with
a specific requirement, at any time.
1 From A-Level Requirements Specification.
2 For B-Level Requirements Specification.
3 To keep things simple please do not use a commercial database – simply save the program’s data in an XML-based
format.
4 You may, optionally save at the time of entry or modification, if you wish.
pf2

Partial preview of the text

Download Requirements Database - Project 1 - Fall 2002 | CSE 784 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!

CSE784 – Software Studio Fall 2002

Project #1 – Requirements Database

B-Specification due Sep 23, code due Sep 30, C-Specification due Oct 7, revised B-Specification due Oct 14

Purpose:

This program captures and saves customer requirements^1 , development requirements^2 , and requirements issues. It provides capability to:  Number each customer requirement, and each development requirement.  Attach an issue statement with any requirement, above. Provide a status for each issue which has one of the two values: open or closed.  Provide a title for each requirement.  Stamp each requirement with a creation time and date and a last modified time and date.  Edit requirements and issues already entered.  Add new, or delete existing, requirements and issues at any time.  Associate a priority (levels High, Normal, or Low) with any requirement’s issue.  Display any requirement by number or title.  Sort requirements by number, title, creation date, last modified date, or priority.  Save and restore the database in a file^3. You may assume that the entire database can fit into memory so your design can read the entire file contents at one time.

Requirements:

Your Requirements program:

  1. Shall read from a database file at startup if one is defined. On process termination, it shall save any entered data to the opened file^4.
  2. Shall save all requirements and issues at program termination, using an XML- based format.
  3. Shall accept from the user a definition of a new requirement item in one of the two categories (1) customer specification, or (2) development specification. It shall , for (2), require the user to select one or more customer specifications to which it is allocated or explicitly indicate that it is a derived requirement.
  4. Each item shall consist of a number, title, time-date stamps, a multi-line text description, and priority setting. Item numbers shall consist of a letter, either A or B, and a number. The numbers shall be generated by the program in consecutive order for each group, A or B.
  5. Shall support addition of a new requirement, modification of an existing requirement, or addition or modification of multi-line issue text, associated with a specific requirement, at any time. (^1) From A-Level Requirements Specification. (^2) For B-Level Requirements Specification. (^3) To keep things simple please do not use a commercial database – simply save the program’s data in an XML-based format. (^4) You may, optionally save at the time of entry or modification, if you wish.

CSE784 – Software Studio Fall 2002

  1. Shall display, on command, any requirement by number or title. If no title matches, shall return the closest matching title^5.
  2. Shall provide a view containing a list of numbers, titles, and dates. It shall provide a way to display a window showing requirement and issue text for any selected requirement.
  3. Shall support sorting by number, title, creation data, last modification date, or priority.
  4. Shall be composed of at least three modules. Each module shall provide a test interface^6 that defines a single public test() function that returns true if all internal tests are successful, otherwise false. Each module shall implement the public test function and whatever internal (private) test functions are necessary to test all the module’s behaviors^7. 10.Each module shall provide a test stub that uses its public test() function and displays results showing that all required functionality is correctly implemented. command line display output file system Requirements Program database filename data items, issues filename,^ file text file text

Figure 1. - Context Diagram for Requirements Program

user input requirements, issue data, commands (^5) This requirement is ambiguous. You will have to elaborate on the meaning of the requirement in your B Specification. (^6) An interface in C++ is an abstract base class. C# has an interface keyword. (^7) The intent here is that you define an abstract base class Testable with a public member function bool test(). Every class in your design derives from Testable and implements the test() function, using some appropriate number of helper test functions.