1. Actor Specification
Actor Name: Designer
Abstract: No
Description: A designer is a human actor who will utilize the system to design software architectures.
Actor Specification
Actor Name: History Database
Abstract: No
Description: The History Database is a system used to store data regarding user actions and inputs. The History Database will not be utilized directly by a user. It will be utilized by a system.
Actor Specification
Actor Name: ArchE Core
Abstract: No
Description: The ArchE core is a nonhuman actor that comprises the rule and fact bases of ArchE in Jess. The ArchE core has the tactics codified as rules that represent the expert knowledge.
Actor Specification
Actor Name: Researcher
Abstract: No
Description: A researcher is a human actor involved in managing the environment of ArchE. A researcher is responsible for setting up the scenario types, reasoning frameworks, and the rules.

2. Actor Specification
Actor Name: Extension Provider
Abstract: No
Description: An extension provider is a human actor involved extended ArchE’s capabilities. Provides additional reasoning frameworks or domain specific knowledge.
Actor Specification
Actor Name: Security Administrator
Abstract: No
Description: A security administrator is a human actor that maintains the access control lists for ArchE. They control modification access to ArchE’s components.
Actor Specification
Actor Name: Jess Rule Engine
Abstract: No
Description: Reference the ArchE Core actor specification.
Actor Specification
Actor Name: System Maintainer
Abstract: No
Description: The System Maintainer is a human actor that supports the Rules Editor by configuring the fact types (requirement, responsibility, and relationship) that are used when adding rule facts.

3. Rule Execution Subsystem Use Case Diagram

4. Rule Editing Subsystem Use Case Diagram

5. Rationale Subsystem Use Case Diagram

6. Configuration Control Subsystem Use Case Diagram

7. High Priority Use Cases
Use case name:
Start Execution
Unique use case ID:
UC101
Primary actor(s):
Researcher
Secondary actor(s):
ArchE Core
Brief Description:
The Researcher starts an execution of the enabled rules, modules, and reasoning frameworks in ArchE. The system executes the rules using the ArchE Core. The system stops executing rules when a breakpoint is reached.
Preconditions:
The researcher is not currently running a rule execution already.
Flow of Events:
The Researcher starts a rule execution.
The system retrieves the rules from the ArchE Core.
The system retrieves the existing breakpoints.
The system detects if there is a loop.
The system steps through the enabled rules until an enabled breakpoint is reached.
Postconditions:
The rule execution is stopped at a breakpoint.
Alternative flows and exceptions:
After detecting there is a loop, the system notifies the Researcher.
If there are no breakpoints enabled, then the system will execute all of the enabled rules.
Nonbehavioral requirements:
N/A
Assumptions:
Issues:
Source:
MSE Studio Project
Son of ArchE
Architecture Expert Design Assistant
Presentation
High Priority Use Cases

8. Use Case Name:
Define the facts
Unique use case ID:
UC001
Primary actor(s):
Designer
Secondary actor(s):
Jess rule engine, System Maintainer
Brief description:
The designer uses slots and inheritance to create requirement, responsibility and relationship facts. This information is held in the fact base of the Jess rule engine.
Preconditions:
The new fact does not exist in the fact base.
Flow of event:
Designer uses the rules editor to invoke the table view in the UI.
Designer creates a new requirement fact by selecting the kind (scenario/function), typing in the description and, in the case of scenario, informing scenario type, value for the six parts. The status is filled automatically.
Designer creates a responsibility fact by typing in the description and, optionally, the values of parameters that define the responsibility.
Designer adds a relationship between two existing responsibilities by selecting precedes, contains or customized. If customized, user can type in a label.
After entering the information in the table view, the fact base is updated to contain the new responsibilities, requirements, and relationships.
Postconditions:
The new facts are available for use.
Priority: 5
Alternative flows and exceptions:
The new requirement, responsibility, or relationship is a duplicate; reject the addition and inform the designer.
Nonbehavioral requirements:
Assumptions:
Issues:
Source:
ArchE_FeatureList_v02, 26/Jan/2006
ArchE_SRS_v2.2[1], 20/Jan/2006

9. Alternative Scenarios
Alternative Name:
Execution not started
ID:
UC101-A1
Actor(s):
Researcher, ArchE Core
Brief description:
After detecting there is a loop, the system does not start the execution and notifies the Researcher.
Insertion point:
Step 4, the system detects if there is a loop.
Preconditions:
The execution has not been started.
Alternative flow of events:
The system detects that there is a loop.
The system notifies the researcher that there is a loop.
Postconditions:
Priority:
Medium
Nonbehavioral requirements:
N/A

10. Alternative Name:
Duplicate rule fact.
ID:
UC001-A1
Actor(s):
Designer
Brief description:
The Rules Editor detects a duplicate fact.
Insertion point:
Step 5, prior to updating the fact base.
Preconditions:
The Rule Fact exists in the fact base of the Jess Rule Engine.
Alternative flow of events:
The new requirement, responsibility, or relationship being added through rules editing is a duplicate and is detected.
The addition is rejected.
A message is displayed to the Designer.
Postconditions:
The Rule Fact is not added to the fact base.
Priority:
High
Nonbehavioral requirements:
N/A

11. View Applicant Information Focus Area
Purpose: Provide access to applicant’s data and status of application process.
Functions
Schedule interview
View application status
Cancel scheduled interview
View application
View supporting information
Edit information
Provide comments
Work Objects
Applicant
Application
Resume
Schedule
Issues
How long is the information retained?
What happens if the position applied for is filled?
Roles
Secretary
Recruiter
Interviewer
View Applicant Information Focus Area

12. First Name: ___________________ Last Name: ______________________
Address: __________________________________
City: ____________________________ State: __ Zip: __________ Phone: (___)___-____
Application
Resume
Comments
Schedule Interview __/__/__
Cancel Interview
Status: _________
Save
Prototype

13. Conduct Interview Focus Area
Purpose: Capture details of the interview with employment candidate.
Functions
View prepared questions
Record candidate responses
Record interviewer comments
Record interviewer recommendation
Links
> View Applicant Information
> Create Offer Package
Work Objects
Applicant
Interview
Interviewer
Position
Issues
How can the interviewer capture all required information without breaking the flow of the interview?
Roles
Recruiter
Conduct Interview Focus Area

14. Applicant’s Information
Interview
Applicant’s Information
Question Set:
Information Technology Specialist 1
Question 1
Question 2
Question 3
Question n
Questions
Candidate Response
Interviewer Comment
Interviewer:
John Smith
Response 1
Response 2
Response 3
Response n
Comment 1
Comment 2
Comment 3
Comment n
Recommendation:
HIRE
Second Interview
DO NOT HIRE
Next set of n Questions
Next Set of Questions
Previous Set of Questions
Conduct Interview Prototype

15. Sequence Diagram ACTIVITY INTENT ABSTRACT STEP Accept Applicants
Review application
Receive application on desk or via
Review resume
Interview Applicants
Set up first interview
Set up second interview
Compare applicant’s experience with required experience
Schedule an interview
Interview applicant
Approve second interview
Sequence Diagram

16. Flow Model for Interview 1U1
(Recruiter)
Review Applications
Interview Applicants
Schedule Interviews
Recommend or Deny Applicants
Secretary
Accept Applications
Provide Comments on Applicants
File Applications
Send Rejection and Offer Letters
Hiring Manager
Interview Applicant
Accept or Reject Applicant
Write Job Description
Applicant
Fill out job application
Attend Interview
Application
Acceptable
Applications
Rejected Applications
Rejection Forms
Acceptable Applications
Notes on First Interview
Application of Accepted Applicant
Offer Letter
Rejection Letter
Schedule
Interview
Flow Model for Interview 1

17. Intent: Review Application
Trigger: Application Received on Desk or via
Review Application
Review Resume
If Provided
Compare Experience with
Required Experience
If applicant is unacceptable send rejection form to secretary
Intent: Set Up Interview
Wait for secretary to set up interview
Interview Applicant
If applicant is acceptable send information to hiring manager
Wait for hiring manager’s decision
If applicant is acceptable have secretary set up second interview

18. Wait for secretary to set up second interview
Interview Applicant
Intent: Set Up Second Interview
If applicant is unacceptable send rejection form to secretary
If applicant is acceptable fill out applicant processing form
Schedule Background Check
Send acceptance form to secretary
Intent: Hire Applicant
Legend
An action that terminates the sequence

19. Physical Model for Interview 1
Chair
Computer C O U N T E R
Office
Space
Cubicle
Storage
Recruiter’s Office
Secretary
Walk applications to
recruiter’s office or
send via
Applicants drop off applications at counter or send applications via to secretary
Physical Model for Interview 1

20. Cultural Model for Interview 1
Federal Regulation and Laws
HR Director
Hiring Manager U1
(Recruiter)
Influence
Roles/Positions
Cultural Model for Interview 1