Project 1 for Software Engineering Studio - Fall 2007 | CSE 784, Study Guides, Projects, Research of Software Engineering

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

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 08/09/2009

koofers-user-jzx
koofers-user-jzx 🇺🇸

10 documents

1 / 2

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CSE784 – Software Studio Fall 2007
Project #1 – Requirements Database Manager
B-Specification due Sep 17, code due Sep 24, C-Specification due Oct 8
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.
Provide a title and keywords for each requirement.
Stamp each requirement with a creation time and date and a last modified time and
date.
Attach3 a multi-line text field for requirement descriptions.
Attach a multi-line issue statement to any requirement, above.
Provide a status for each issue which has one of the two values: open or closed.
Associate a priority (High, Normal, or Low) with any requirement’s issue.
Edit all fields of existing requirements except for number and time/date stamp.
Edit text, status, and priority for any existing issue.
Add new, or delete existing, requirements and issues at any time.
Display any requirement by number or title.
Display all issues of a specified priority.
Search for all requirements that match specified keywords, title fragment4, or number
range.
Sort requirements by number, title, creation date, last modified date, or issue
priority5.
All changes to requirements data must be persistent.
Support the display of a test description and, or, test procedure for a selected
requirement.
Support the execution of one or more tests for a selected requirement.
Support stepping through the requirements display according to some user defined
sequence.
Requirements:
Your Requirements program:
1. Shall read from a database file at startup if one is defined. All changes to the data store
shall be persistent6.
2. 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 from which it is allocated
or explicitly indicate that it is a derived requirement.
3. Each item shall consist of a type7, number, title, keywords, time-date stamps, a multi-
line text description, and priority setting. Item numbers shall be integers, generated by
the program in consecutive order for each type. Each development requirement shall
also support allocation information, e.g., allocation from one or more customer
requirements or derived requirement.
1 From A-Level Requirements Specification.
2 For B-Level Requirements Specification.
3 Here, attach means that the text is not, by default, shown in the user interface, but may be
displayed by some simple user action, like a double click on a requirement statement.
4 Must support the use of wildcards.
5 High priority issues first, then normal, low, and finally requirements with no attached
issues.
6 Please use SQL Server.
7 Customer or Developer
pf2

Partial preview of the text

Download Project 1 for Software Engineering Studio - Fall 2007 | CSE 784 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!

CSE784 – Software Studio Fall 2007

Project #1 – Requirements Database Manager

B-Specification due Sep 17, code due Sep 24, C-Specification due Oct 8

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.  Provide a title and keywords for each requirement.  Stamp each requirement with a creation time and date and a last modified time and date.  Attach^3 a multi-line text field for requirement descriptions.  Attach a multi-line issue statement to any requirement, above.  Provide a status for each issue which has one of the two values: open or closed.  Associate a priority (High, Normal, or Low) with any requirement’s issue.  Edit all fields of existing requirements except for number and time/date stamp.  Edit text, status, and priority for any existing issue.  Add new, or delete existing, requirements and issues at any time.  Display any requirement by number or title.  Display all issues of a specified priority.  Search for all requirements that match specified keywords, title fragment^4 , or number range.  Sort requirements by number, title, creation date, last modified date, or issue priority^5.  All changes to requirements data must be persistent.  Support the display of a test description and, or, test procedure for a selected requirement.  Support the execution of one or more tests for a selected requirement.  Support stepping through the requirements display according to some user defined sequence.

Requirements:

Your Requirements program:

  1. Shall read from a database file at startup if one is defined. All changes to the data store shall be persistent^6.
  2. 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 from which it is allocated or explicitly indicate that it is a derived requirement.
  3. Each item shall consist of a type^7 , number, title, keywords, time-date stamps, a multi- line text description, and priority setting. Item numbers shall be integers, generated by the program in consecutive order for each type. Each development requirement shall also support allocation information, e.g., allocation from one or more customer requirements or derived requirement. (^1) From A-Level Requirements Specification. (^2) For B-Level Requirements Specification. (^3) Here, attach means that the text is not, by default, shown in the user interface, but may be displayed by some simple user action, like a double click on a requirement statement. (^4) Must support the use of wildcards. (^5) High priority issues first, then normal, low, and finally requirements with no attached issues. (^6) Please use SQL Server. (^7) Customer or Developer

CSE784 – Software Studio Fall 2007

  1. Shall support the display of all developer requirements derived from some specified customer requirement.
  2. Shall support addition of a new requirement, modification of an existing requirement, or addition or modification of multi-line issue text^8 , associated with a specific requirement, at any time.
  3. Shall support the deletion of any requirement or issue. Deletion shall not cause any requirement number to change.
  4. Shall provide a Graphical User Interface that provides at least two views:
    • A list view with all but multi-line text fields displayed, one line per requirement
    • A text view displaying the requirements and possibly issue text for any selected requirement.
  5. The default display behavior of the list view shall show all requirements, using scrolling or paging as necessary.
  6. Shall provide the means to search for requirements by title fragment, keywords, time/date range, or number range.
  7. Shall support sorting by number, title, creation date, last modification date, or priority.
  8. Shall support display of test description, test procedure, and test execution, for each requirement in a user-defined sequence and support single-stepping through the sequence^9.
  9. Shall be composed of at least three modules. Each module shall provide a bool test() function that tests its internal functionality.
  10. Each module shall provide a test stub that displays results showing that all required functionality is correctly implemented. The executive module shall provide a test stub that exercises its own functionality and executes each module’s test() functions to demonstrate that this program satisfies its requirements. Output of this test shall be written to an XML file, and the contents of the test file displayed in a popup window, if, and only if, the user requests that action via a command line switch.

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 (^8) Note that this is not the same as the multi-line requirements text for a requirement item. (^9) At each step in the sequence, the test description and procedure are displayed, and the user can cause a predefined test to execute.