Final Report

 

The following definitions provide a vocabulary for a discussing of my research.

 

Requirement- desired property of the system.

GoalÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ - high level objective of the business, organization or system. They capture the reasons why a system is needed and guide decision at various levels within the enterprise [Ant96].

Scenario ÝÝÝÝÝÝÝÝ - possible sequence of actions or system behaviorsÝ [AP98].

 

Scenario management and goal identification are challenging. Scenario management is challenging due to the number of possible relations among scenarios grow with grow of the scenarios. If relations are formalized the job to identify and support them becomes easier [AAB99].Ý The challenges that analysts face with goal identification is usually due to the large goal sets which often contain redundancies and are subject to misinterpretation. It is very hard to keep track of scenarios and goals. Software engineers need tool support for managing large sets of scenarios and goals.

 

The SMaRT (Scenario Management and Requirements Tool) is a web based tool designed for project requirements collection and analysis. It incorporates GBRAT1 (Goal-Based Requirements Analysis Tool) and the heuristics provided by GBRAM2 (Goal-Based Requirements Analysis Method). SMaRT provides a graphical user interface for recording goals, requirements, and scenarios, making it possible to measure similarities of scenarios. During the summer of 2001, I designed and implemented a powerful database backend for the SMaRT.

 

ÝFigure 1 shows the entity-relationship diagram for the SMaRT database.

SMaRT contains set of users, projects, goals, requirements, scenarios, episodes and events. Each entity in the diagram is represented by an oval. Each goal has set of pre-conditions, post-conditions, obstacles, constraint, and issues. The relationship between goal and given entities is many-to-many. For example: one goal can have many issues and one issue can belong to many goals. This kind of relationship requires extra table, which is represented by square on the diagram.

 

Each scenario contains sets of obstacle, constraint, issues, and conditions (It is possible for a constraint to be a pre-condition for one and a post-condition for another scenario). The relationship between a scenario and these entities is many-to-many. Scenario can also consist of episodes or/and events (a unique pair of actor and action represents an event). Similarly, episodes can contain other episodes and/or events. The extra table <Episode_Episode> resolved this ìcircularî problem.

 

The database contains a set of user and their profiles. There are two kinds of users: administrator and analyst, as defined in the entity <user_type>.Ý The relationship between user and its type is one-to-many. This type of represented by 1:M on the diagram.ÝÝ

 

 

 

 

 


Based on the entity-relationship diagram and requirements document for theSMaRT I createdÝ the database tables structure. Appendix A contains a list of the tables with their attributes. Each tables contains primary key, it is represented as underlined field.

Ý

Once the database was designed, I researched various databases in order to decide which one was most appropriate. I decided not to use Oracle since it is expensive on a per-processor license ($15K), and it is not efficient to buy a "single user" license for a web applications. PostgreSQL and MySQL are the two top competing free database systems, to my knowledge. PostgreSQL is a sophisticated Object-Relational DBMS (DataBase Management System), supporting almost all SQL constructs, including sub-selects, transactions, and user-defined types and functions. Since it uses standard SQL it should be relatively simple to migrate.

 

I have a separate machine for the database server (queries can be offload onto the DB server allowing the web server to keep serving files

 

ÝI implemented the SMaRT database by interacting directly with PostgreSQL. I had to use the terminal window and raw SQL..

 

After the database was up and running I decided upon the kinds of integrity to enforce and entered the tables into the system. Presently, SMaRT contains 36 tables, here is an example of one of them:

 

CREATE TABLE Goal(

goal_id varchar(6),

goal_key_word varchar(15),

goal_desc text,

source_id varchar(6),

PRIMARY KEY (goal_id),

FOREIGN KEY (source_id) REFERENCES Source

ON DELETE RESTRICT

ON UPDATE CASCADE);

 

The documentation on the structure of the database is contained in the table_struc_sql.rtf file. In addition I organized and entered goals from the CommerceNet case study and from the Internet Privacy Policy web security project; however, I was not been able to enter goals from meting scheduler project.Ý Documentation on CommerceNet data contained in the Cnet_data.rtf document, and on the web security in the web_data.rtf. Back up for SQL code is in Cnet_data_sql.rtf and web_data_sql.rtf, accordingly. Following is example of code to enter goal in the <Goal> table:

 

INSERT INTO goal (goal_id, goal_key_word, goal_desc) VALUES ('av0001', 'AVOID', 'AVOID obsolete information' );

 

I encountered extra problems while working with the database. The structure of the database cannot be modified sufficiently. ALTER command to drop a column in the table does not work in PostgreSQL. The user has to drop a table and then reenter it without a column in question. The problem that rises is about data in the table. I observed another problem with the SQL code: it is case sensitive.

Search: SELECT * FROM goal WHERE goal_key_word =îuseî; will not work, but SELECT * FROM goal WHERE goal_key_word =îUSEî; will. This constraint requires the user to know the structure of the data before its usage.

 

There is still some work to be done. This work will be continued by Paul Zaremba and Thomas Alspaugh this Fall. The rest of the data has to be entered to the database and the SQL code for searching and formatting data needs to beÝ written. Also, it would be beneficial to test the database for data contents, size and fit as well as integrity. The database needs to be bounded with the user interface.

 

 

1GBRAM are the systematic application of heuristics and inquire questions for analysis of goals, scenarios and obstacles. [AP98]

 

2GBRAT tool is designed to support goal-based requirements analysis. The tool provides procedural support for the identification, elaboration, requirement and organization of goals to specify the requirements. [ALR96]

Appendix A

 

Action

Actor

Condition

Constraint

Event

action_id

actor_id

condition_id

constraint_id

event_id

action_desc

actor_desc

condition_desc

constraint_desc

actor_id

action_key_word

actor_name

source_id

source_id

action_id

 

 

 

 

 

 

 

 

 

 

Episode

Episode_Event

Episode_Episode

Episode_Scenario

Goal

episode_id

episode_id

episode1_id

scenario_id

goal_id

episode_desc

event_id

episode2_id

episode_id

source_id

issue_id

 

 

 

goal_desc

source_id

 

 

 

goal_key_word

 

 

 

 

 

 

 

 

 

 

Goal_Constraint

Goal_Obstacle

Goal_Issue

Goal_Obstacle

Goal_Pre_Condition

goal_id

goal_id

goal_id

goal_id

goal_id

constraint_id

obstacle_id

issue_id

obstacle_id

pre_id

 

 

 

 

 

 

 

 

 

 

Goal_Project

Goal_Post_Condition

Goal_Requirement

Goal_Scenario

Issue

goal_id

goal_id

goal_id

goal_id

issue_id

project_id

post_id

reqt_id

scenario_id

issue_desc

status

 

 

 

source_id

 

 

 

 

 

 

 

 

 

 

Obstacle

Pre_Condition

Post_Condition

Project

Requirement

obstacle_id

pre_c_id

post_c_id

project_id

reqt_id

obstacle_desc

pre_c_desc

post_c_desc

project_name

project_id

source_id

source_id

source_id

status

reqt_desc

 

 

 

project_desc

 

 

 

 

project_lead

 

 

 

 

 

 

 

 

 

 

 

Scenario

Scenario_Condition

Scenario_Constraint

Scenario_Event

Scenario_Issue

scenario_id

scenario_id

scenario_id

scenario_id

scenario_id

project_id

condition_id

constraint_id

event_id

issue_id

scenario_name

status

 

 

 

status

 

 

 

 

stakeholder

 

 

 

 

project_id

 

 

 

 

source_id

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Scenario_Obstacle

Scenario_Requirement

Source

User_Info

User_Project

scenario_id

scenario_id

source_id

u_id

project_id

obstacle_id

reqt_id

s_name

u_password

u_id

 

 

s_interview_transcripts

u_first_name

 

 

 

s_person_name

u_middle_name

 

 

 

s_location

u_last_name

 

 

 

s_hypertext_link

u_street_addr

 

 

 

 

u_apartment_no

 

 

 

 

u_city

 

User_type

 

 

u_state

 

u_type_id

 

 

u_zip_code

 

u_type_key_word

 

 

u_country

 

 

 

 

u_phone

 

 

 

 

u_work_street_add

 

 

 

 

u_work_city

 

 

 

 

u_work_state

 

 

 

 

u_work_zip_code

 

 

 

 

u_work_country

 

 

 

 

u_work_phone

 

 

 

 

u_fax

 

 

 

 

u_email_addr

 

 

 

 

u_last_modified

 

Bibliography

 

[ALR96] A.I. AntÛn, E. Liang and R.A. Rodenstein. ìA Web-Based Requirements Analysis Tool.î In 5th Work. on Enabl. Technol.: Infrastruct. For Collab. Ent., pp. 238-243, June 1996.

 

[AP98] A.I. AntÛn and C. Potts. ìThe Use of Goals to Surface Requirements for Evolving Systems.î IEEE International Conference on Software Engineering (ICSE í98), 19-25 April 1998, pp. 157-166.

 

[AAB99] T.A. Alspaugh, A.I. AntÛn, T. Barnes and B.W. Mott. ìAn Integrated Scenario Management Strategy.î

 

 

[AP98] A.I. AntÛn and C. Potts. ìThe Use of Goals to Surface Requirements for Evolving Systems.î IEEE International Conference on Software Engineering (ICSE í98), 19-25 April 1998, pp. 157-166.

TroubleÝ

 

[Ant96] A.I. AntÛn. ìGoal-Based Requirements Analysis.î 2nd IEEE International Conference on Requirements Engineering (ICRE í96), Colorado Springs, Colorado, 15-18 April 1996, pp. 136-144.