[Sandcastle]-ArchitecturalDriversSpecification

Sandcastle -- tên nhóm
Architectural Drivers Specification 1.0
ACDM Architecture Tool -- tên dự án
Ahn, Cho, Chotemateepirom, Haider, Zgraggen - tên thành viên

10/10/2008 - update
Sandcastle Team - update 11 July 2024
Revision History
Date Version Author Description
Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 2of 39

Contents
1 Introduction.........................................................................................................................................6
1.1 Purpose........................................................................................................................................6
1.2 Definitions, Acronyms and Abbreviations....................................................................................6
1.3 Change Process............................................................................................................................7
2 Project Overview.................................................................................................................................7
3 Architectural Drivers Overview............................................................................................................7
4 Functional Requirements.....................................................................................................................8
4.1 Template......................................................................................................................................8
4.2 Specifications...............................................................................................................................8
4.2.1 Allow designers to capture, categorize, and refine architectural drivers.............................8
4.2.2 Provide a drawing palette for rendering structures in views in the static, dynamic, and
physical perspective that provide a collection of predefined elements and relationship types that
are consistent with respect to perspective..........................................................................................9
4.2.3 Allow designers to define their own elements and relationship types..............................10
4.2.4 Provide a way to create element and relationship catalogs..............................................10
4.2.5 Allow designers to capture design rationale......................................................................11
4.2.6 Allow designers to explicitly assign architectural drivers to design decisions....................11
4.2.7 Provide a way for designers to define element “interfaces” statically, dynamically, and
physically11
4.2.8 Allow designers to map elements to elements within a perspective.................................11
4.2.9 Allow designers to map elements to elements across perspectives..................................12
4.2.10 Provide the ability to use UML as a vocabulary for detailed design drawings...................12
4.2.11 Provide the ability to warn users when various design obligations have not been met....12
4.2.12 Allow designers to save, load, delete, and rename projects..............................................12
4.2.13 Allow designers to edit projects after they have been saved.............................................13
4.2.14 Facilitate collaborative design by allowing a community of designers to use the tool to
define and update the design............................................................................................................13
4.2.15 All interaction between designers and the tool will be through a graphical user interface
13
4.2.16 Print (or Presentation mode) formatting requirements.....................................................13
4.3 Specifications Traceability Matrix..............................................................................................13
4.4 Use Case Modeling....................................................................................................................14

4.4.1 Domain Model...................................................................................................................14

4.4.2 Entities...............................................................................................................................14
4.4.3 Use Case List......................................................................................................................15
4.4.4 Use Cases...........................................................................................................................16
5 Quality Attribute Requirements........................................................................................................34
5.1 Template....................................................................................................................................34
5.2 Quality Attribute Scenarios........................................................................................................35
6 Constraints........................................................................................................................................38
6.1 Technical Constraints.................................................................................................................38
6.2 Business Constraints..................................................................................................................39
7 Prioritization......................................................................................................................................39
7.1 Priority scale..............................................................................................................................39
7.2 Difficulty ranking scale...............................................................................................................39
7.3 Use Cases...................................................................................................................................40
7.4 Quality Attribute Scenarios........................................................................................................41
7.5 Constraints.................................................................................................................................41
7.5.1 Technical Constraints.........................................................................................................41
7.5.2 Business Constraints..........................................................................................................42
7.6 Significant Architectural Drivers................................................................................................42
8 Default shapes...................................................................................................................................42
8.1 Dynamic perspective..................................................................................................................42
8.1.1 Element types....................................................................................................................42
8.1.2 Relationship types..............................................................................................................44
8.2 Static perspective.......................................................................................................................44
8.2.1 Element types....................................................................................................................44
8.3 Physical perspective...................................................................................................................45
8.3.1 Element types....................................................................................................................45
9 Warning rules....................................................................................................................................46
10 Addendum.....................................................................................................................................46

1 Introduction - update
1.1 Purpose
This document will be used to record, communicate and refine the architectural drivers for the project.
This document will act as the main repository of requirements for the length of the project.
The intended audience for this document is the Sandcastle team and the customer. These stakeholders
are to review the document and changes will be incorporated as per the change management process of
the Sandcastle team. [SOW08]
1.2 Definitions, Acronyms and Abbreviations
2 Project Overview - update

(mô tả dự án vé xe bus online)
The ACDM Architecture Tool is a tool that will allow the software architect to draw diagrams of design of
the software to be developed. Detailed project goals and all relevant contextual information for this
document is presented in the [SOW08] document.
3 Architectural Drivers Overview

(giải thích ý nghĩa tài liệu architecture driver)

The architectural drivers presented in this document include:
 Functional Requirements: These requirements are presented in the form of specifications and
use cases. These are a refinement of the requirements documented in the raw requirements
specification [RS08] document.
 Quality Attribute Requirements: These requirements are presented in the form of quality
attribute scenarios. These scenarios are based on the quality attributes documented in the raw
requirements specification [RS08] document.
 Business Constraints: These are the business constraints documented in the raw requirements
 Technical Constraints: These are the technical constraints documented in the raw requirements
These architectural drivers will influence the architectural design and implementation of the project.
Additionally, they will impact the schedule and quality of the project. As a whole these architectural
drivers define the scope of the project.
The elicitation process by which these architectural drivers were gathered is detailed in the [PDP08]
document.
4 Functional Requirements
4.1 Template
Title of functional requirement ID: unique identifier.
specification Priority: priority integer based on the priority table.
Version: integer version number.
Last Changed: Date this specification was last changed. Both Version and
this field will be changed at the same time. Only changes that affect the
functionality should affect these two fields, and not minor grammatical
changes.
Description of the requirement specification.
Open Issues: These are any ambiguities or conflicts in requirements that need to be clarified with the client.
Additionally, these can be issues that the team needs to solve on their own.
4.2 Specifications
Prioritization scale has been defined in section 7.1.
ID: FR1
4.2.1 Allow designers to capture, categorize, and refine Priority: 1
architectural drivers Version: 1
Last Changed: 11/22/2008
Architecture drivers should be categorized in the following categories:
 Functional Requirement
 Quality Attribute Scenarios

 Technical Constraint
 Business Constraint
Users cannot define their own categories.
Information to be captured for each architecture driver is listed in [lat08] (stage 2). Functional requirements should
use the use case and entity templates. Quality attribute scenarios should use the 6 step template ([lat08] page
222, chapter 9, Table9.16). Simple templates for business and technical constraints are also present in [lat08].
The architect should be prompted to enter the architectural drivers before they create the design. This should be
done in an unobtrusive way. Also, for each architecture driver, a certain list of actions should be performed
(writing prose description, rationale). If these actions are not performed, the user should be notified, again in an
unobtrusive way.
Refining architectural drivers will be facilitated in allowing annotations on elements. Architecture drivers will be
mapped onto elements or relationships, and thus there will be a collection of annotations attached with a driver.
(see requirements traceability table for related requirements)
The purpose of this feature is to have users use the tool as the primary storage for their architectural drivers. Thus
the interface and features for this requirement must allow them to perform the basic tasks of adding and editing
data and also take into account other features that they might need.
More detail about usage of architecture drivers in FR6.

Open Issues
ID: FR2
4.2.2 Provide a drawing palette for rendering structures Priority: 1
in views in the static, dynamic, and physical
perspective that provide a collection of predefined Version: 1
elements and relationship types that are consistent Last Changed: 11/22/2008
with respect to perspective
List of element and relationship types to have in predefined list for each perspective (see section 8 for more
information):
 Dynamic
o Process
o Threads
o Objects
o Data store
o Data flow
o Events
o Interrupts
o Call return
 Static
o Modules
o Procedure
o Class
o Uses
o Inherits
 Physical

o Anything in the physical world
The tool will provide the user the ability to create multiple views in a particular perspective that will act as
canvases for architectural diagrams.
In each view, an element or relationship must have a unique name. (see FR3 for more information)
Open Issues
ID: FR3
4.2.3 Allow designers to define their own elements and Priority: 1
relationship types Version: 1.1
Each perspective will have its own set of element and relationship types. Across perspectives, the name of an
element and relationship type must be unique. There will be no check on the actual way the element or
relationship looks.
When creating a custom element or relationship type, the following information should be asked:
 Ask whether it is an element or relationship
 Get a name
 Get a description
 Restricted to which perspective.
o Search for the same name in all perspectives and warn the user. Don’t allow them to
create a duplicate. No duplicates across perspectives.
 Drawing of the element type. In case of a relationship type, it would just be properties of how
the line and arrowheads look.
Users should be able to take a predefined element or relationship type, modify it and save it as a custom type.
There should also be a quick way to revert back to default element and relationship types.
The user should be able to specify the color and attributes for different parts of the element and relationship
types.
All shapes should be portable and should be packaged within a file if it uses custom shapes. When custom shapes
are created, the default behavior should be to have those custom shapes only visible at that project level.
Open Issues
There should be an option to promote a custom shape to the application level, to make it available to other
projects.
ID: FR4
4.2.4 Provide a way to create element and relationship Priority: 1
catalogs Version: 2.1
The element and relationship catalogs will be at the view level. It will be a table containing all elements and
relationships in the view, with the following information provided for each:
 Element: "Responsibilities", "Provides", and "Requires"
 Relationship: "Responsibilities"

 Group: "Responsibilities".
The user should be able to enter these values (as plain text) directly into the relationship catalog.
Open Issues
ID: FR5
4.2.5 Allow designers to capture design rationale Priority: 1
Version: 1
Rationale is attached with each view of a perspective. Rationale will be in the form of prose.
Open Issues
ID: FR6
4.2.6 Allow designers to explicitly assign architectural Priority: 1
drivers to design decisions Version: 1
The user must be allowed to manually assign an architectural driver to particular elements and relationships in the
architecture.
The architecture drivers will be used in the tool in the following ways:
1. Assign to elements or relationships
2. Assign to a decomposition mapping (between an element and a view)
3. Assign to a mapping between elements or groups of elements (FR8 & FR9)
The assignment must propagate down to child elements and relationships when an element is decomposed.
Decomposing an element will result in a view. The decomposed element and the resulting view will have a parent
child relationship.
Architectural drivers cannot be assigned to views.

Open Issues
ID: FR7
4.2.7 Provide a way for designers to define element Priority: 3
“interfaces” statically, dynamically, and physically Version: 1
Interfaces are at the code level. This is a tentative requirement.
Open Issues
ID: FR8
4.2.8 Allow designers to map elements to elements Priority: 1
within a perspective Version: 1
The user must be allowed to group elements together, and create mappings between elements or groups of
elements in the same perspective.

Additionally, the user should be allowed to create mappings between views.

The mappings type can be hierarchical or non-hierarchical.
They should be able to describe the mappings using prose.
Open Issues:
ID: FR9
4.2.9 Allow designers to map elements to elements Priority: 2
across perspectives Version: 1
The user must be allowed to perform the same operations as in FR8 for elements and groups of elements and
views in different perspectives.
Open Issues
ID: FR10
4.2.10 Provide the ability to use UML as a vocabulary for Priority: 3
detailed design drawings Version: 1
Not required at the moment.
Open Issues
ID: FR11
4.2.11 Provide the ability to warn users when various Priority: 2
design obligations have not been met Version: 2
The user must be warned in the following cases (See section 9 for details):
 Not assigning architecture drivers to elements and relationships.
 Not having a rationale for a view.
 Not having element relationship catalogues. The user needs to enter the details for catalogues.
 There’s a missing perspective.
The above warnings could be shown as ‘compiler warnings’ as an example.
The user can customize their own design obligations. They should be allowed to manage a todo list in which they
can add task titles and priorities. They should have the ability to mark a task as completed and be able to delete
tasks.
Open Issues
ID: FR12
4.2.12 Allow designers to save, load, delete, and rename Priority: 1
projects Version: 1.1
 Have only one project open in the application at a time.
Open Issues
 Custom shapes should be bundled with a file and imported by the tool on a different machine.
Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 10

of 39
ID: FR13
4.2.13 Allow designers to edit projects after they have Priority: 1
been saved Version: 1
Open Issues
ID: FR14
4.2.14 Facilitate collaborative design by allowing a Priority: 3
community of designers to use the tool to define Version: 1
and update the design Last Changed: 11/22/2008
Not required at the moment.
Open Issues
ID: FR15
4.2.15 All interaction between designers and the tool will Priority: 1
be through a graphical user interface Version: 1
Open Issues
ID: FR16
4.2.16 Print (or Presentation mode) formatting Priority: 3
requirements Version: 1
Format and convert the contents of a file to a Microsoft Word document so the user can manually format the
document and create a print ready version.
Open Issues
 We need to design this in more detail. We can discuss our design with the client when we have
it.
4.3 Specifications Traceability Matrix --- (optional)

This traceability matrix identifies dependencies between functional requirements. Dependencies are
identified based on explicit dependencies mentioned in the text of the functional requirement
specifications and implicit dependencies that are implied by the functions being documented. E.g.
consider the dependency between FR1 and FR2, which exists because architectural drivers captured in
FR1 are mapped to elements created in FR2 (in this case, the dependency originates from FR6).

of 39
FR1 FR2 FR3 FR4 FR5 FR6 FR7 FR8 FR9 FR10 FR11 FR12 FR13 FR1 FR15 FR16
4
FR1 X X X X X X X
FR2 X X X X X X X X
FR3 X X X X X
FR4 X X X X X X
FR5 X X X X X X
FR6 X X X X X X X X X X
FR7
FR8 X X X X X X
FR9 X X X X X X
FR10
FR11 X X X X X X
FR14
FR15 X X X X X X X X X X X X
FR16 X X X X X X X X X
4.4 Use Case Modeling

4.4.1 Domain Model
Domain Object Description
Use case A collection of information that the end user will enter into the tool. This collection will
include: Title, ID, Description, Entities Involved, Preconditions, Primary use case flow of
events, Primary use case postconditions, Alternate user case flow of events, Alternate use
case postconditions.
Entity A collection of information that the end user will enter into the tool. This collection will
include: Name, ID, Description, Provides Assumptions, Requires Assumptions, Identified user
cases.
Quality attribute A collection of information that the end user will enter into the tool. This collection will
include: Title of scenario, ID, Quality attribute, Description of stakeholder’s role, Source of the
stimulus, Stimulus, Relevant environmental conditions, Architectural elements, System
response, and Response measure.
Business A collection of information that the end user will enter into the tool. This collection will
constraint include: ID, Title, Consideration.
Technical A collection of information that the end user will enter into the tool. This collection will
constraints include: ID, Title, Consideration.
Element type A collection of information that the end user will enter into the tool. This collection will
include: Type, Name, Description, Perspective.
Relationship type A collection of information that the end user will enter into the tool. This collection will
include: Type, Name, Description, Perspective.
4.4.2 Entities
Entity name: Đặt Vé Xe Online Entity ID: E01
Description:
Architects are people who use the tool to design their software intensive system they want to build. They are the

of 39
only end users of the tool. Architects are assumed to be familiar with ACDM, adept at using computers, and
responsible for creating and maintaining architectures based on the ACDM methodology.
Provides assumptions:
Architects have gathered the architectural drivers and finished ACDM stage 2.
Requires assumptions:
Architects expect no interruptions from the tool. He wants the freedom to draw the design in various ways. The
only feedback the Architects expect from the tool are warnings if the design is not consistent and regulations from
the ACDM methodology are not met.
Identified use cases:
Architects are the single entity for this tool. Therefore, all the use cases are identified for this entity.
4.4.3 Use Case List

UC ID UC Title FR ID
UC01 Capture functional requirement FR1
UC02 Capture quality attribute FR1
UC03 Capture technical constraint FR1
UC04 Capture business constraint FR1
UC05 Create/Remove a view FR2
UC06 Draw a design in a view FR2
UC07 Define new element or relationship type FR3
UC08 Edit element or relationship type FR3
UC09 Remove element or relationship type FR3
UC10 Reset toolbox FR3
UC11 Manage element and relationship catalogs FR4
UC12 Capture design rationale for view FR5
UC13 (‘Capture design rationale for an element, relationship or group’ is removed – at
version 1.6)
UC14 Assign/Remove an architectural driver to/from an element/relationship/ group FR6
UC15 View/Remove an element or relationship to which an architectural driver is FR6
assigned
UC16 Decompose an element/relationship/group FR6, FR8
UC17 Create a mapping between different views FR8
UC18 Create a mapping for element/relationship/group FR8
UC19 Delete a mapping FR8
UC20 Capture design rationale for a mapping FR5, FR8
UC21 Assign/Remove architectural drivers to/from a mapping of elements FR8, FR9
UC22 Use UML to draw detail design FR10
UC23 Warn user about unmet design obligations FR11
UC24 (silence warning is removed – at version 1.2)
UC25 Manage tasks for the project FR11
UC26 Manage a project FR3, FR12
UC27 Export a project FR16
UC28 Group elements and relationships FR8
UC29 Ungroup elements and relationships FR8
UC30 View decomposition of an element FR6, FR8
UC31 Export an architecture project to a document format FR16

of 39
4.4.4 Use Cases
4.4.4.1 Capture functional requirement

Use case title: Capture functional requirements Use case ID: UC01
Version: 1
General use case description:
Architect will add/edit/delete functional requirement.
Entities involved:
E01 – Architect
Preconditions:
None.
Primary use case flow of events:
1. E01 selects the architectural drivers view.
2. E01 selects the functional requirement view.
3 If E01 wants to add a functional requirement,
1. E01 enters a use case.
4. If E01 wants to delete a functional requirement,
1. E01 selects a use case.
2. E01 deletes the selected use case.
5. If E01 wants to edit a functional requirement,
1. E01 selects a use case.
2. E01 edits the selected use case.
Alternate use case 3.1 flow of events:
1. E01 can add a new entity for the use case
2. E01 enters an entity.
1. E01 can delete an entity for the use case
2. E01 selects the entity.
3. E01 deletes the entity.
1. If the functional requirement is assigned to something in the drawing. E01 will be asked to confirm it if he
still wants to proceed.
2. The system will delete all related assignments.
1. E01 can edit an entity for the use case
2. E01 selects the entity.
3. E01 edits the entity.
Primary use case postconditions:
The functional requirement is saved in the system.
4.4.4.2 Capture quality attribute

Use case title: Capture quality attribute Use case ID: UC02
Version: 1
Architect will add/edit/delete a quality attribute.
Entities involved:

of 39
E01 – Architect
Preconditions:
None.
2. E01 selects the quality attributes view.
3. If E01 wants to add a quality attribute,
1. E01 enters a quality attribute.
4. If E01 wants to remove a quality attribute,
1. E01 selects a quality attribute.
2. E01 deletes the quality attribute.
5. If E01 wants to edit a quality attribute,
1. E01 selects a quality attribute.
2. E01 edits the quality attribute.
1. If the quality attribute is assigned to something in the drawing. E01 will be asked to confirm it if he still
wants to proceed.
The quality attribute is saved in the system.
4.4.4.3 Capture technical constraint

Use case title: Capture technical constraint Use case ID: UC03
Version: 1
Architect will add/edit/delete a technical constraint
Entities involved:
E01 – Architect
Preconditions:
None.
2. E01 selects the technical constraints view.
3. If E01 wants to add a technical constraint,
1. E01 enters a technical constraint.
4. If E01 wants to remove a technical constraint,
1. E01 selects a technical constraint.
2. E01 deletes the technical constraint.
5. If E01 wants to edit a technical constraint,
1. E01 selects a technical constraint.
2. E01 edits the technical constraint.
1. If the technical constraint is assigned to something in the drawing. E01 will be asked to confirm it if he still
wants to proceed.
The technical constraint is saved in the system.

of 39
4.4.4.4 Capture business constraint

Use case title: Capture business constraint Use case ID: UC04
Version: 1
Architect will add/edit/delete a business constraint
Entities involved:
E01 – Architect
Preconditions:
None.
2. E01 selects the business constraints view.
3. If E01 wants to add a business constraint,
1. E01 enters a business constraint.
4. If E01 wants to remove a business constraint,
1. E01 selects a business constraint.
2. E01 deletes the business constraint.
5. If E01 wants to edit a business constraint,
1. E01 selects a business constraint.
2. E01 edits the business constraint.
1. If the business constraint is assigned to something in the drawing. E01 will be asked to confirm it if he still
wants to proceed.
The business constraint is saved in the system.
4.4.4.5 Create/Remove a view

Use case title: Create/Remove a view Use case ID: UC05
Version: 1
Architect can create/remove a view from perspectives.
Entities involved:
E01 – Architect
Preconditions:
None.
1. E01 selects a perspective.
2. If E01 wants to create new view,
1. E01 selects the option to create view.
2. E01 enters name for the view.
3. The system creates the view.
3. If E01 wants to remove a view,
1. E01 selects a view from the list.
2. E01 selects the option to remove the view.
3. E01 confirms removing the view.

of 39
The view is created or removed to the selected perspective.

1. If the name that E01 entered is already exist in the project, E01 needs to choose another name.
1. If the view is mapped to another view, E01 will be asked if he wants to proceed and delete the view and its
mappings.
2. The system deletes the view, its mappings and all child elements, relationships and their assignments,
mappings and child views (or decomposed elements).
4.4.4.6 Draw a design in a view

Use case title: Draw a design in a view Use case ID: UC06
Version: 3
Architect can draw diagram to the view.
Entities involved:
E01 – Architect
Preconditions:
A view exists and is currently being viewed.
2. E01 selects a view.
3. If E01 wants to add an element or relationship,
1. E01 selects an element or relationship from the toolbox of the current perspective.
2. E01 adds the selected element or relationship to the view.
3. E01 names element or relationship.
4. If E01 wants to remove an element or relationship,
1. E01 selects an element or relationship in the view.
2. E01 select the option to remove the element or relationship from the view.
3. The system deletes all assignments, and mappings for the element or relationship.
5. If E01 wants to edit name of element or relationship,
1. E01 selects an element or relationship in the view.
2. E01 renames the element or relationship.
6. The system updates the diagram.
The changes are reflected on the diagram.
1. E01 does not have to specify a name for an element or relationship.
Alternate use case 3.3 and 5.2 flow of events:
1. If an element with the name that E01 entered already exists in the same view, E01 needs to choose another
name.
1. If the element or relationship has a mapping to another element or group, or if the element has an assigned
architectural drivers, the E01 will be asked if he wants to proceed and delete the element or relationship
and delete the mapping or assignment
1. If the element has a mapping to a decomposed view E01 will be given the choice of removing just the
element, or the element and its child view together.
Note: An Element and a Relationship can’t have the same name.

of 39
4.4.4.7 Define new element or relationship type

Use case title: Define new element or relationship Use case ID: UC07
type Version: 1.1
An architect creates new element and relationship type.
Entities involved:
E01 – Architect
Preconditions:
None.
2. If E01 selects the option to add a new element type,
1. E01 specifies values for new element type.
2. E01 draws the new element type in the drawing area. The drawing area includes basic shapes and
supports the change of the line type (full, dots, etc), and the drawing color.
3. If E01 selects the option to add a new relationship type,
1. E01 specifies values for new relationship type.
2. E01 specifies properties of the line (full, dots, etc), and the line color.
The changes are reflected on the element and relationship type list. This new type will be visible only
in project level, not in application level.
Alternate use case 2.1 and 3.1 flow of events:
1. If the name that E01 entered already exists in the element and relationship type list in the same
perspective, E01 needs to choose another name.
Alternate use case 2 and 3 flow of events:
1. E01 can choose to use an existing element or relationship type to create a new element or relationship.
2. The system will then use the existing element or relationship type as a base. But only the shape is used. The
name, description etc. are removed and have to be entered by the user.
Open Issues
4.4.4.8 Edit element or relationship type

Use case title: Edit element or relationship type Use case ID: UC08
Version: 1.1
An architect edits an element or relationship type.
Entities involved:
E01 – Architect
Preconditions:
An element or relationship type exists.
2. E01 selects the element or relationship type.
3. E01 selects the option to edit this element or relationship type.
4. E01 changes the values for the element or relationship type (Type, Name, Description and look and feel).
5. E01 makes changes to the element or relationship type in the drawing area.
6. The system updates the element or relationship both on the toolbox and on the canvas.
The changes are reflected on the element and relationship type toolbox. The change will affect project

of 39
level, not application level.

Alternate use case 4 flow of events:
1. If the name that E01 entered already exists in the element and relationship list in the same perspective, E01
needs to choose another name.
Open Issues
4.4.4.9 Remove element or relationship type

Use case title: Remove element or relationship type Use case ID: UC09
Version: 1.1
An architect removes an element or relationship type.
Entities involved:
E01 – Architect
Preconditions:
An element or relationship type exists.
2. E01 selects the element or relationship type.
3. E01 selects the option to remove this element or relationship type.
4. E01 confirms removing the element or relationship type.
5. System removes the element or relationship type.
The changes are reflected on the element and relationship list. The change will affect project level, not
application level.
1. If the element or relationship type has instances in the drawing then it is not possible to delete the type.
Inform E01 accordingly.
Open Issues
4.4.4.10 Reset toolbox

Use case title: Reset toolbox Use case ID: UC10
Version: 1.1
An architect resets the toolbox. This will remove all the custom shapes the user defined.
Entities involved:
E01 – Architect
Preconditions:
None
1. E01 selects the option to reset the toolbox.
2. E01 confirms removing the element or relationship type.
3. The system updates the element or relationship both on the toolbox and on the canvas.
The changes are reflected on the element and relationship list. The change will affect project level, not
application level.
1. If some element or relationship types have instances. E01 will be asked if he wants to delete all the other

of 39
custom shapes which don’t have instances.

Open Issues
4.4.4.11 Manage element and relationship catalogs

Use case title: Manage element and relationship Use case ID: UC11
catalogs Version: 2.1
Architects can provide information for each element, relationship, or group in the view.
Entities involved:
E01 – Architect
Preconditions:
An element or relationship is already created.
1. E01 selects a perspective and view.
2. E01 selects the option to manage catalogs.
3. The system shows the catalog of the view.
4. If E01 selects an element,
1. E01 edits information or enters new information.
Information includes “Responsibilities”, “Requires” and “Provides”.
5. If E01 selects a relationship or group,
1. E01 edits information or enters new information.
Information includes “Responsibilities”.
Information is updated to the catalogs.
4.4.4.12 Capture design rationale for view

Use case title: Capture design rationale for view Use case ID: UC12
Version: 1
Rationale is attached to each view of a perspective. Rationale will be in the form of prose.
Entities involved:
E01 - Architect
Preconditions:
A view is already created.
1. E01 selects the view and selects the option to capture rationale.
2. The system shows the current rationale of the selected view.
3. E01 edits rationale or enters new rationale.
The rationale is saved to the selected view.
4.4.4.13 Capture design rationale for an element, relationship or group
4.4.4.14 Assign/Remove an architectural driver to/from an element/relationship/group of

elements and relationships
Use case title: Assign/Remove an architectural Use case ID: UC14
driver to/from an element/relationship/group Version: 3

of 39

Architects can assign and unassign an architectural driver to particular elements and relationships or
groups of them in the architecture.
Architectural drivers cannot be assigned to views.
Entities involved:
E01 – Architect
Preconditions:
An element or relationship is already created. At least one element or relationship or a group exists.
1. E01 selects an element or relationship or a group.
2. If E01 wants to assign an architectural driver to the selected element or relationship or group,
1. E01 selects the option to assign an architectural driver.
2. The system shows the list of architectural drivers of the project.
3. E01 selects an architectural driver from the list.
4. The system assigns the selected architectural driver to the element or relationship or group.
3. If E01 wants to remove an assigned architectural driver from the selected element or relationship or group,
1. E01 selects the option to remove an architectural driver.
2. The system shows the list of architectural drivers assigned to the element or relationship.
3. E01 selects the option to remove architectural driver that they want to remove.
4. E01 confirms removing the selected architectural driver.
5. The system removes the assignment between the element or relationship or group and the selected
architectural driver.
The selected architectural driver is assigned/removed to/from the selected element or relationship
or group.
1. The system shows a warning because the architectural driver is already assigned to this element or
relationship or group.
Open Issues
4.4.4.15 View/Remove an element or relationship to which an architectural driver is assigned

Use case title: View/Remove an element or Use case ID: UC15
relationship to which an architectural driver is Version: 2
assigned
Architects can view elements or relationships assigned to architectural drivers in the project.
Entities involved:
E01 – Architect
Preconditions:
Architectural drivers are already created. At least one element or relationship exists.
1. E01 selects an architectural driver.
2. The system shows a list of all elements and relationships assigned to that particular architectural driver.
3. If E01 wants to remove an assigned element or relationship from the selected architectural driver,
1. E01 selects the option to remove an assigned element or relationship.
2. The system shows the list of elements and relationships assigned to the architectural driver.
3. E01 selects the element or relationship that wants to remove from the list.
4. E01 confirms removing the selected element or relationship.
5. The system removes the selected element or relationship from the list.

of 39

The selected element or relationship is assigned to/removed from the selected architectural driver.
Open Issues
4.4.4.16 Decompose an element/relationship/group

Use case title: Decompose an element Use case ID: UC16
Version: 1
Architect can decompose an element/relationship/group. Decomposing an
element/relationship/group will result in a view. This element/relationship/group will be linked
hierarchically with the view.
Entities involved:
E01 – Architect
Preconditions:
An element is already created and not decomposed yet.
1. E01 selects the element.
2. E01 selects the option to decompose.
3. E01 enters name for the decomposing view.
4. E01 confirms creating the decomposing view.
5. The system saves the decomposing view. The view is linked hierarchically to the element.
The decomposing view of the selected element is created.
1. If the name that E01 entered already exists in the project, E01 needs to choose another name.
Open Issues
4.4.4.17 Create a mapping between different views

Use case title: Create a mapping between different Use case ID: UC17
views Version: 2
E01 can map a view to another view. It makes no difference if the two views are in the same
perspective or not.
Entities involved:
E01 - Architect
Preconditions:
There are existing views.
1. E01 opens the relationship view.
2. E01 selects the option to map the view to another view.
3. E01 selects the source view for the mapping.
4. E01 selects the target view for the mapping.
5. E01 enters the details (type of link, prose description) for the mapping.
6. E01 confirms all the changes
7. The system saves the changes.
The system has saved the changes and applies them.

of 39
1. E01 can also select a view from a different perspective.

1. E01 can also select a view from a different perspective.
1. The system checks if the mapping already existed (same source and target), return error to user.
Open Issues
4.4.4.18 Create a mapping for elements/ relationships/ groups.

Use case title: Create a mapping for groups. Use case ID: UC18
Version: 2
E01 can map an element, a relationship or a group to an relationship, element or group. This mapping
is possible within a view or between views or even between different perspectives. The exception is
that it is not possible to map a element/relationship/group to an element/relationship/group within
the same view; this would be a relationship.
Entities involved:
E01 - Architect
Preconditions:
There are existing element/relationship/group.
1. E01 selects an element/relationship/group.
2. E01 selects the option to map the selection to an element/relationship/group.
3. The system shows a dialog to specify details about the mapping.
4. E01 selects a perspective which contains the target for the mapping.
5. E01 selects a view which contains the target for the mapping.
6. E01 selects the target of the mapping which could be an element/relationship/group.
7. E01 enters the details (type of link, prose description) for the mapping.
8. E01 confirms all the changes
9. The system saves the changes.
1. If a view is the target of the mapping, E01 does not have to perform step 6.
1. The system checks if the mapping already existed (same source and target), return error to user.
Note: The system should also allow to map a view to an element/relationship/group.
4.4.4.19 Delete a mapping

Use case title: Delete a mapping Use case ID: UC19
Version: 1
E01 can delete a mapping.
Entities involved:
E01 – Architect
Preconditions:
There are existing mappings.
1. E01 opens the relationship view.

of 39
2. E01 selects the mapping.

3. E01 deletes the mapping.
4. The system asks the user if he really wants to delete this mapping including all the design rationale for this
mapping.
5. E01 confirms this question to delete the map.
6. The system deletes the map and shows the changes.
4.4.4.20 Capture design rationale for a mapping

Use case title: Capture design rationale for a Use case ID: UC20
mapping Version: 1
The architect can attached rationale to mappings.
Entities involved:
E01 – Architect
Preconditions:
A view is selected. The elements and the mapping exist.
1. E01 selects an element.
2. E01 views detailed information of element.
3. E01 selects one of the mappings.
4. E01 edits rationale or enters new rationale.
5. E01 saves the change.
The rationale is saved to selected element.
4.4.4.21 Assign/Remove architectural drivers to/from mapping of elements

Use case title: Assign/Remove an architectural Use case ID: UC21
driver to/from mapping of elements Version: 1
Architects can assign an architectural driver to mappings between elements.
Entities involved:
E01 – Architect
Preconditions:
A mapping exists.
1. E01 selects an element.
2. E01 views detailed information of element.
3. E01 selects one of the mappings.
2. If E01 wants to assign an architectural driver to the selected mapping,
1. E01 selects the option to assign an architectural driver.
2. The system shows the list of architectural drivers of the project.
3. E01 selects an architectural driver from the list.
4. The system assigns the selected architectural driver to the mapping.
3. If E01 wants to remove an architectural driver from the selected mapping,
1. E01 selects the option to un-map an architectural driver.

of 39
2. The system shows the list of architectural drivers assigned to the mapping.
3. E01 selects the architectural driver that wants to remove from the list.
4. E01 confirms removing the selected architectural driver.
5. The system removes the selected architectural driver from the list.
The selected architectural driver is assigned/un-assigned to/from the mapping in the element.
1. The system shows a warning because the architectural driver is already assigned to this element or
relationship.
4.4.4.22 Use UML to draw detailed design

Use case title: Use UML to draw detail design Use case ID: UC22
Version: 1
The system should support the use of UML to draw the detail design
Entities involved:
E01 – Architect
Preconditions:
The system must have an open project with at least one view.
1. E01 opens the UML toolbox.
3. If E01 wants to add an UML element,
1. E01 selects an element from the UML toolbox.
2. E01 adds the UML element to the view.
3. E01 enters name for the UML element.
4. If E01 wants to remove UML element,
1. E01 selects an UML element in the view.
2. E01 deletes the UML element in the view.
5. If E01 wants to edit name of UML element,
1. E01 selects an UML element in the view.
2. E01 renames the UML element.
4.4.4.23 Warn user about design

Use case title: Warn user about design obligations Use case ID: UC23
which have not been met Version: 5
E01 should be warned if design obligations have not been met.
Entities involved:
E01 – Architect
Preconditions:
None
1. E01 makes a change to the architecture.
2. The system evaluates the changes.
 Not having mapped an architectural driver to an element, relationship or group.

of 39
 Not having a rationale for a view.

 Not having element relationship catalogs. The user needs to enter the ‘provides &
requires’ for catalogs.
 There’s a missing perspective.
3. The system updates a list of warnings.
E01 received feedback for the design obligations which have not been met.
1. E01 changes the perspective.
2. The system shows the warnings of the selected perspective if there are any.
1. E01 opens the design warnings.
2. E01 can choose which design warnings he wants to see. (all, static, dynamic, physical)
3. The system shows the user all design obligations which were not met for his selections.
Note:
The tool will not allow the user to hide a warning.
4.4.4.24 Silence warnings
4.4.4.25 Manage tasks for the project

Use case title: Manage tasks for the project Use case ID: UC25
Version: 1
Architects can create, update, and delete their tasks (to-do list).
Entities involved:
E01 – Architect
Preconditions:
None
1. E01 opens the task panel.
2. The system shows the current tasks.
3. If E01 wants to add the task,
1. E01 selects the option to add new task.
2. E01 enters the description and priority for the task.
3. E01 saves the task.
4. If E01 wants to edit the task,
1. E01 selects the task to be edited and selects the option to edit.
2. E01 edits the description and priority of the task.
3. E01 saves the task.
5. If E01 wants to remove the task,
1. E01 selects the task.
2. E01 selects the option to remove the task.
3. E01 confirms removing the task.
6. If E01 wants to specify that the task is complete or incomplete,
1. E01 selects the task.
2. E01 selects the option to complete or incomplete the task.
5. If E01 wants to sort the tasks by description or priority
1. E01 selects the description or priority.

of 39
2. E01 starts the sort operation.

3. The system sorts the tasks according to the criteria.
7. The system saves the task and indicates to architect that the task is saved.
The task is saved.
4.4.4.26 Manage a project

Use case title: Manage a project Use case ID: UC26
Version: 1.1
E01 can create, save, rename, and load projects.
Entities involved:
E01 – Architect
Preconditions:
None
1. If E01 wants to create a new project,
1. E01 chooses the create project dialog.
2. If another project is working
1. The system asks E01 to save and close that project.
2. The system saves and closes that project.
3. E01 enters the name for the project.
4. The system creates the project.
2. If E01 wants to save a project,
1. E01 saves the project.
2. The system writes the data into the file.
3. If E01 wants to rename a project,
1. E01 selects the option to rename the project.
2. E01 enters the new name for the project.
3. The system saves the new project name.
4. If E01 wants to load a project,
1. E01 opens the load dialog.
2. If another project is working
1. The system asks E01 to save and close that project.
2. The system saves and closes that project.
3. E01 selects a project the system should load.
4. The system loads the project.
The system has saved and applied the changes.
1. The system warns the user and asks for another filename if a project with this filename already exist.
Open Issues
4.4.4.27 Export a project

Use case title: Export a project Use case ID: UC27
Version: 2

of 39
E01 should have the possibility to export the whole project into a file that they can use to print.
Entities involved:
E01 – Architect
Preconditions:
None
1. E01 selects the option to export the whole project to a different format.
2. E01 enters the name for the new file.
3. The system exports all the architectural drivers, diagrams and related information to the new file.
Alternate use case #1 flow of events:
1. E01 selects a drawing which he wants to export.
2 E01 selects the option to export this drawing as a picture.
3. E01 enters the filename for the picture.
4. The system saves just this drawing in a picture.
4.4.4.28 Group elements and relationships

Use case title: Group elements and relationship Use case ID: UC28
Version: 2
An architect creates a group of elements, relationships, and groups.
For now we have implemented a group as a simple rectangular layer that the user can draw. No rules
are associated with a group.
Entities involved:
E01 – Architect
Preconditions:
A view is selected.
1. E01 selects elements, relationships, and groups.
2. E01 creates a group with the elements, relationships, and groups.
3. E01 enters a name for the group (if they want to).
4. E01 saves the change.
The changes are reflected on the view.
1. If the selected elements or relationships are already in another group, the system will not allow this
grouping and show error message.
1. If the name that E01 entered is already in this view, E01 needs to choose another name.
1. If a rectangle enclosing only the group members cannot be drawn, the tool will not allow the group to be
created.
Note (rules of grouping):
For now we ignore all those rules.
1. The tool will not allow users to have one element to be in more than one group. But, it is
ok for a group to contain other groups.
2. If a rectangle enclosing only the group members cannot be drawn, the tool will not allow
the group to be created.

of 39
3. The tool will not allow users to resize the group if all components inside the group
cannot be fit in the group; otherwise the tool will allow users to resize the group.
4. In the case that users drag and drop new element into the group, the tool should
automatically add that element into the group.
5. In the case that users drag and drop element out of the group, the tool should
automatically remove that element out of the group.
6. Empty group are not allowed. So, when users remove components out of the group, the
tool have to check if the group will not be empty.
Open Issues
We considered that it might be hard to implement the tool to allow users to resizing the group. If it
affects our plan, we might need to discuss with the client early; if he still wants to have this feature, it
might affect the scope of the project.
4.4.4.29 Ungroup elements and relationships

Use case title: Ungroup elements and relationship Use case ID: UC29
Version: 1
An architect decides to ungroup a group of elements and relationships.
Entities involved:
E01 – Architect
Preconditions:
A view is selected.
1. E01 selects a group of elements and relationships.
2. E01 selects the option to ungroup.
3. E01 confirms.
4. The system removes the grouping, updates the canvas and removes any mappings and assignments for this
group.
The changes are reflected on the view.
4.4.4.30 View decomposition of an element

Use case title: View decomposition of an element Use case ID: UC30
Version: 2
Architect can view the decomposition of an element.
Entities involved:
E01 - Architect
Preconditions:
An element is already created.
1. E01 selects the element.
2. E01 selects the option to view the decomposition.
3. The system opens the decomposing view of the element.
The decomposing view of the selected element is shown to the user.

of 39
4.4.4.31 Export an architecture project to a document format

Use case title: Export an architecture project to a Use case ID: UC31
document format Version: 1
Architect can export an architecture project to a document format.
Entities involved:
E01 - Architect
Preconditions:
A project is already created.
1. E01 selects an option to export the project to a document.
2. The system opens a dialog that allows E01 to arrange architecture information.
3. E01 arranges architecture information before exporting.
4. E01 selects an option to export arranged format.
5. The system creates a document file that contains all of the architecture information.
A document file is created with all of the architecture information arranged by E01.
5 Quality Attribute Requirements

Quality attributes are the benchmarks that describe a system’s intended behavior within the
environment for which it was built. They provide the means for measuring the fitness and suitability of a
product. These requirements will have an effect on the architectural design and implementation of the
product.
5.1 Template
The following template will be used to present the quality attribute scenarios for this project.
Title of scenario: Descriptive ID: Mnemonic reference if desired Version: revision number of scenario
title if desired Last Changed: when the last change
was made in MM/DD/YYYY format.
Quality attribute: The one- Characterization ID: The ID of the stage 1 characterization used as a basis for this
word quality attribute scenario
characterization
Describe stakeholder role proposing the description: The stakeholder(s) or stakeholder communities interested in
this quality attribute scenario
Source(s) of the stimulus Description of the originating source(s) or potential sources of the stimulus or
stimuli that will result in a system response.
Stimulus Phenomenon, event, situation, etc., that prompts the system or stakeholders to
react in some way or take some action. It might be a user request, an event or
interrupt, an error, a request for change, and so forth.
Relevant environmental Description of any relevant environmental conditions that could affect the
conditions response and the measures of the response. It might include such conditions as
normal operation, peak load, degraded operation, at development time, during

of 39
operation, without interrupting operation, and so forth.

Architectural elements System elements affected by the stimulus. Early in the development life cycle
(prearchitectural design) the affected elements might not be known or may be a
very high-level description. As design commences, scenarios should be refined
and elements identified as they are known.
System response Desired response of the system. This should be as specific as possible because
this will be how the system will be designed to respond to the stimulus.
Response measure(s) Measure by which the quality of the response will be measured. Response
measures depend on the quality attribute. Response measures vary and may be
in terms of person-hours, error detection, response time, recovery time, and so
forth.
Associated risks In the course of analyzing the quality attribute descriptions, the architectural
design team may discover risks associated with satisfying the quality attribute
requirement. These will largely be technical, but may include other issues that
will influence later design decisions.
5.2 Quality Attribute Scenarios

The following quality attribute scenarios will be refined during the design stage, as the team gets a
clearer idea of the architecture and detail design and the implications they have on these scenarios. It is
most likely that new quality attribute scenarios will be added during the design phase.
Title of scenario: Freedom when drawing shapes ID: QAS1 Version: 1

Quality attribute: Usability Characterization ID: QA2
Describe stakeholder role proposing the description: End user, Customer and Maintainer
Source(s) of the stimulus Architect
Stimulus Need for the tool to allow architects to concentrate on creating the architectural
representation without worrying about restrictions imposed by the tool.
Relevant environmental When the architect is creating the design.
conditions
Architectural elements The drawing canvas and shape palette subsystems of the tool.
System response The system should not make any inputs as required when an element is added to
the canvas.
Response measure(s) The architect shouldn’t be forced to do things in a particular sequence or limited
in the number or types of elements in a perspective.
Associated risks There might be some restrictions imposed by elements that are part of a UML
palette. There might be some difficulty in determining which restrictions are
reasonable without restricting flexibility.
Title of scenario: Intuitiveness of user interface (UI) of perspectives ID: QAS2 Version: 1
and their views Last Changed: 11/22/2008
Stimulus The tool must make obvious the relationships between UI elements (perspective,
view, mapping etc.).
conditions

of 39
Architectural elements The visual hierarchy of the system. Partitioning of the perspective, view,
architectural driver and mapping subsystems.
System response The system should visually arrange options and visual elements such that the
hierarchy between perspectives and views is evident. Operations on
perspectives, views, architectural drivers and mappings must preserve the
context in which they are being performed. Difference between mappings and
relationships must be made evident.
Response measure(s) The architect is able to understand the logical relationship between perspectives,
views, mappings, and assignments, and perform a set of relevant tasks, on the
first use of the tool, with an hour of instruction.
Associated risks The user may have a different understanding of the terms used in the tool.
Title of scenario: Keyboard shortcuts ID: QAS3 Version: 1

Stimulus Need for the tool to allow the user to efficiently perform repeating tasks in a
familiar manner.
conditions
Architectural elements Input subsystem of the tool.
System response The system should have shortcuts for common operations such as save.
Additionally, it should have shortcuts for basic operations specific to the tool such
as creating a view.
Response measure(s) In general, the user should find the tool efficient to use. They should not have to
find a way to perform a routine operation (such as save) by using the mouse. The
user should not need to look through the help of the system to find out shortcuts
for common operations.
Associated risks N/A
Title of scenario: Quick installation procedure ID: QAS4 Version: 1

Quality attribute: Ease of Installation Characterization ID: QA4
Stimulus The user wants to install the software.
Relevant environmental When the architect is installing the software. They just have the tool (on a CD or
conditions other media device) and a computer to install it on. Access to the Internet is
assumed to be absent.
Architectural elements Installation subsystem of the tool.
System response The system should ask the user a minimal set of information during the
installation and should not require the user to make any technical changes
related to the operating environment of the tool (e.g. JVM settings, Windows
environment settings).
Response measure(s) A typical end user should be able to install the system with no intervention (just
simple yes/no prompts) in the first try and should not need to seek help (either
online or in person).
Associated risks Effects of portability on this scenario.

of 39
Title of scenario: Portability to non Windows platforms ID: QAS5 Version: 1

Quality attribute: Portability Characterization ID: QA3
Source(s) of the stimulus Engineering team with source code of the tool and a non Windows platform.
Stimulus The engineering team wants to port to the tool to their non Windows platform.
Relevant environmental The engineering team is coding changes into the tool.
conditions
Architectural elements Degree to which subsystems rely on platform specific operations.
System response The code of the tool should be platform independent.
Response measure(s) The engineering team should be able to port the tool without making significant
changes to the architecture of the tool.
Associated risks Any third party libraries that are used might have platform dependencies that the
team is not aware of. Certain features might require platform dependant code.
Title of scenario: Ability to add features ID: QAS6 Version: 1

Quality attribute: Extensible/Modifiable Characterization ID: QA1
Source(s) of the stimulus Engineering team with source code of the tool and a non Windows platform.
Stimulus The engineering team wants to add a new feature to the tool.
Relevant environmental The engineering team is examining the design document.
conditions
Architectural elements Partitioning of the various subsystems.
System response The design document should have a section detailing how certain parts of the
system may be extended.
Response measure(s) It must be possible to add additional features without significantly changing the
design of the system.
Associated risks The team is not aware of the type of new features that might be added. The team
needs to focus on this requirement early on in the design phase, otherwise it will
result in a lot of effort during the implementation phase.
Title of scenario: Ability to add new types of default shapes or ID: QAS7 Version: 2
relationships Last Changed: 4/12/2009
Source(s) of the stimulus Engineering team with design and source code of the tool
Stimulus The engineering team wants to add new types of default shapes or relationships.
conditions
Architectural elements The domain models and the views
System response The design document should have a section detailing how new types of default
shapes or relationships may be added. Also, it should provide the design of the
shapes and relationships that could be added to the system.
Response measure(s) It must be possible to add new default shapes or relationships without changing
the design of the system.

of 39
Title of scenario: Ability to add new properties to elements ID: QAS8 Version: 1

of 39

Source(s) of the stimulus Engineering team with design and source code of the tool
Stimulus The engineering team wants to add new properties to elements.
conditions
Architectural elements The model, controller, and view
System response The design document should have a section detailing how new properties of
elements may be added.
Response measure(s) It must be possible to add new properties of elements without changing the
design of the system.
6 Constraints
Constraints on the system act as premade design decisions that the development team has to adhere to.
Technical and business constraints for this project are provided below.
6.1 Technical Constraints

Consideration Technical Constraint
Computer language The system will be built using Java (JDK 6).
Commercial software Any commercial or open source software/hardware used as part of the tool must
products be approved by the customer.
Computer platform The tool will not utilize Eclipse. It is not built on any third party platform.
User Interface The tool will not utilize a browser for its primary interface.
Protocols, interfaces, The customer will approve the coding standards used by the team.
standards
Tools and methods Designs will be reviewed and approved by the customer.
6.2 Business Constraints

Consideration Business Constraint
Mandatory regulatory  The team will utilize the Architecture Centric Design Method
restrictions and demands (ACDM) to guide the design of the tool and will adhere to the design
principles listed in [Lat08]. The customer will teach the team ACDM.
 The team will select a subset of the architectural drivers to design
and implement those, subject to the approval of the customer.
Organizational restrictions The customer will be the technical advisor for the project.
and demands
7 Prioritization
7.1 Priority scale
Priority Priority Description
(numeric) (name)

of 39
1 Must Have Must be present in the end product at all costs.

2 Nice to Have Customer would greatly appreciate implementation of these features.
3 If There’s Time Consider in Fall 09 semester if customer deems them important enough.
7.2 Difficulty ranking scale

The difficulty scale has been defined on the basis of complexity and effort. Complexity is defined as how
difficult the design of a solution is and whether the team has previous experience in designing or
implementing such a design. Both measures, for complexity and effort, are relative to each other.
Difficulty Description
(numeric)
1 High complexity and large amount of effort required
2 High complexity or large amount of effort required
3 Moderate complexity and medium amount of effort required
7.3 Use Cases

Use Case prioritizations
ID & Title Stakeholder Difficulty Comments
priority ranking
UC01 - Capture functional requirement 1 2
UC02 - Capture quality attribute 1 2
UC03 - Capture technical constraint 1 3
UC04 - Capture business constraint 1 3
UC05 - Create/Remove a view 1 3
UC06 - Draw a design in a view 1 1
UC07 - Define new element or 1 1
relationship type
UC08 - Edit element or relationship type 1 2
UC09 - Remove element or relationship 1 2
type
UC10 - Reset toolbox 1 2
UC11 - Manage element and relationship 1 3
catalogs
UC12 - Capture design rationale for view 1 3
UC13 - Capture design rationale for an 1 3
element, relationship or group
UC14 - Assign/Remove an architectural 1 1
driver to/from an element or relationship
or a group
UC15 - View/Remove an element or 1 2
relationship to which an architectural
driver is assigned
UC16 - Decompose an element 1 2
UC17 - Create a mapping between 1 2
different views
UC18 - Create a mapping for groups 1 2

of 39
UC19 - Delete a mapping 1 3

UC20 - Capture design rationale for a 1 3
mapping
UC21 - Assign/Remove architectural 2 2
drivers to/from a mapping of elements
UC22 - Use UML to draw detail design 3 1
UC23 - Warn user about unmet design 2 2
obligations
UC25 - Manage tasks for the project 2 2
UC26 - Manage a project 1 3
UC27 - Export a project 3 1
UC28 - Group elements and relationships 1 2
UC29 – Ungroup elements and 1 2
relationships
UC30 – View decomposition of an 1 3
element
UC31 - Export an architecture project to a 1 2
document format
7.4 Quality Attribute Scenarios

Quality Attribute Scenario prioritizations
ID & Title Stakeholder Difficulty Comments
priority ranking
QAS1 - Freedom when drawing shapes 1 3 The difficulty ranking does not take
into account the ranking of the
underlying drawing subsystem.
QAS2 - Intuitiveness of user interface (UI) 1 2
of perspectives and their views
QAS3 - Keyboard shortcuts 2 3
QAS4 - Quick installation procedure 1 3
QAS5 - Portability to non Windows 3 2
platforms
QAS6 - Ability to add features 1 2 The complexity will be high, and that
will need to be tackled during the
design phase.
QAS7 - Ability to add new types of default 1 2
shapes or relationships
QAS8 - Ability to add new properties to 2 2 We will do this again when the data
elements model is designed.
7.5 Constraints
Constraints have not been prioritized in terms of importance because by definition they are of the
highest priority. We have however prioritized them by difficulty, as judged by the development team.
7.5.1 Technical Constraints

Technical constraint prioritizations

of 39
Description Difficulty Comments

ranking
Use Java 3
Third party libraries need to be 2 The team might not be able to use some libraries that could
approved by customer potentially reduce the implementation effort.
Must not be based on Eclipse 2 Using Eclipse could have reduced implementation effort.
Must not utilize a web browser 3
Coding standards will be 3
approved by customer
Design will be reviewed and 3 This will help the team in improving their design skills, and
approved by customer improve quality of their design.
7.5.2 Business Constraints

Business constraint prioritizations
Description Difficulty Comments
ranking
Team will use ACDM during 2 Team is unfamiliar with ACDM, thus might not properly use the
the development lifecycle methodology throughout the lifecycle.
Customer will be the technical 3
advisor for the team
7.6 Significant Architectural Drivers

The following architectural drivers have been given a high priority by the customer and have been
ranked by the engineering team as being of high difficulty. Thus these should be given preference when
making any decisions that affect architectural drivers.
Architectural Drivers Comments

UC06 - Draw a design in a view
UC07 - Define new element or relationship There are open issues with regards to the portability of custom
type types between different instances of the tool.
UC14 - Assign/Remove an architectural driver
to/from an element or relationship

of 39
References
[PDP08] Sandcastle Team, Problem Definition Proposal, 2008-09
[RS08] Sandcastle Team, Requirements Specification, 2008-09
[SOW08] Sandcastle Team, Statement of Work, 2008-09
[Lat08] Lattanze, A. Architecting Software Intensive Systems: A Practitioners Handbook, New York, NY:
Auerbach, 2008

of 39

[Sandcastle]-ArchitecturalDriversSpecification

Uploaded by

Copyright:

Available Formats

You might also like

[Sandcastle]-ArchitecturalDriversSpecification

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

[Sandcastle]-ArchitecturalDriversSpecification

Uploaded by

Copyright:

Available Formats

Sandcastle -- tên nhóm

Architectural Drivers Specification 1.0

ACDM Architecture Tool -- tên dự án

Ahn, Cho, Chotemateepirom, Haider, Zgraggen - tên thành viên

Date Version Author Description

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 2of 39

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 3of 39

4.4.1 Domain Model...................................................................................................................14

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 4of 39

1.2 Definitions, Acronyms and Abbreviations

2 Project Overview - update

3 Architectural Drivers Overview

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 5of 39

The architectural drivers presented in this document include:

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 6of 39

More detail about usage of architecture drivers in FR6.

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 7of 39

o Anything in the physical world

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 8of 39

Architectural drivers cannot be assigned to views.

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 9of 39

Additionally, the user should be allowed to create mappings between views.

The above warnings could be shown as ‘compiler warnings’ as an example.

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 10

4.3 Specifications Traceability Matrix --- (optional)

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 11

4.4 Use Case Modeling

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 12

4.4.3 Use Case List

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 13

4.4.4 Use Cases

4.4.4.1 Capture functional requirement

4.4.4.2 Capture quality attribute

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 14

4.4.4.3 Capture technical constraint

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 15

4.4.4.4 Capture business constraint

4.4.4.5 Create/Remove a view

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 16

The view is created or removed to the selected perspective.

4.4.4.6 Draw a design in a view

Note: An Element and a Relationship can’t have the same name.

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 17

4.4.4.7 Define new element or relationship type

4.4.4.8 Edit element or relationship type

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 18

level, not application level.

4.4.4.9 Remove element or relationship type

4.4.4.10 Reset toolbox

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 19

custom shapes which don’t have instances.

4.4.4.11 Manage element and relationship catalogs

4.4.4.12 Capture design rationale for view

4.4.4.13 Capture design rationale for an element, relationship or group

4.4.4.14 Assign/Remove an architectural driver to/from an element/relationship/group of

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 20

Last Changed: 12/3/2008

4.4.4.15 View/Remove an element or relationship to which an architectural driver is assigned

Chotemateepirom, Cho, Ahn, Haider, Zgraggen Page 21