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.

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.

Rule Execution Subsystem Use Case Diagram

Rule Editing Subsystem Use Case Diagram

Rationale Subsystem Use Case Diagram

Configuration Control Subsystem Use Case Diagram

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

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

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

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

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

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

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

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

Sequence Diagram ACTIVITY INTENT ABSTRACT STEP Accept Applicants Review application Receive application on desk or via email 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

Flow Model for Interview 1 U1 (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

Intent: Review Application Trigger: Application Received on Desk or via E-mail 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

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

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 e-mail Applicants drop off applications at counter or send applications via e-mail to secretary Physical Model for Interview 1

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