hephaestus requirements - cs. web viewmatlab. a tool and ... they must rely on word of mouth,...

[Hephaestus Requirements]

2012Drexel UniversityCS 493

Tejprakash GillJohn HaasPatrick LocknerPhil MaconiJonathan MonteiroAlex Rybak

1

Version InformationVersion 1.02/7/2012

- Initial document

Version 1.15/1/2012- Updated use case tables to include interface mockups- Removed dedicated interface mockup section

2

1 INTRODUCTION1.1 Purpose

This document details the functional and non-functional requirements of the Hephaestus materials engineering portal, a component of the Materials Genome Initiative. These requirements directly address the performance, interface, functionality, and constraints of the system. Hephaestus is a web-based portal that contributes to materials research by providing researchers with a centralized tool focused on data storage, analysis, and collaboration.

1.2 Materials Genome ProjectIn June 2011, President Obama proposed that accelerating the pace of discovery and deployment of advanced material systems will be crucial to achieving global competitiveness in the 21st century [1]. The primary goal of the Materials Genome Initiative is to discover, develop, manufacture, and deploy advanced materials at least twice as fast as is currently possible, at a fraction of the cost.

1.3 ScopeThis document describes the software requirements for the initial release of Hephaestus. The audience of this document is exclusively developers, testers, and stakeholders of the Hephaestus portal.

1.4 Definitions, Acronyms, and AbbreviationsANG A format for storing sample data MAT A file type used by MATLAB MATLAB A tool and programming language that supports complex computations MTex Quantitative texture analysisParaview An open-source data visualization engineRAW A binary file format in which the data has not been processed RVE An abbreviation for representative volume elementsTIFF Abbreviation for ‘tagged image file format’. This format is

commonly used in scientific imaging.

1.5 OverviewThe remainder of this document is organized into three primary sections: an introduction to the project, its requirements, and a projected system evolution.

3

2 OVERALL DESCRIPTION2.1 Motivation

The field of materials engineering suffers from isolation between different groups of researchers. Raw experimental data and analysis is largely contained within individual labs, which is problematic due to the prohibitive costs, in time and money, of conducting materials research.

Additionally, such isolation has resulted in data being stored in a manner that is not easily shared between different groups. There is no standardized way to store and share the data. When research teams wish to work with external data, at least one of the involved parties needs to spend valuable resources converting the data format to one that the other parties can utilize.

Another issue is that discovering previously completed research is difficult, since there is no searchable catalog of data samples and analyses. This leads to replication of data, wasting time and money on each duplicate sample. This is understandable for sensitive research in industry, but common materials available to all in academia are also subject to this problem.

On top of a lack of searchable catalog, materials researchers have no dedicated method of communicating their research goals and intents other than the resources allocated to them. They must rely on word of mouth, conventions, and inquiries coming to them from outside their own department.

2.2 System ScopeHephaestus is a web-based portal that attempts to alleviate these issues by providing the following high-level features to its users:

- Upload and share material samples with customizable levels of access control

- Perform and share analyses on uploaded samples- Allow users to search for specific samples or analysis results- Facilitate collaboration between researchers through social networking

tools- Provide system access through an exposed service interface

2.3 Sample InformationMaterials engineering sample data is organized, essentially, as images. Samples can be categorized as 2D or 3D. In a 2D sample, a single image can be used to convey the characteristics of a material at each pixel. Different color values are used to represent different material composition values. In addition to the pixel-level details contained within a sample, there are also a number of different

4

pieces of information relating to the sample as a whole – such as the material type and pixel step size. A 3D sample is simply a series of 2D slices of a material aggregated together. A single 2D slice of a 3D sample can be seen in Figure 1, below.

Figure 1: Alpha-Beta Ti Sample

In addition to their raw data, samples can also have segmentation maps applied to them. The segmentation map highlights areas of interest within a sample – but doesn’t modify the underlying sample data. A segmentation map is essentially a color mask. An area that is of interest is assigned a color code. All similar areas receive the same color. Areas that are not of interest are blacked out. An example of the above sample masked by a segmentation map can be seen in Figure 2.

5

Figure 2: Alpha-Beta Ti Sample, Segmented

Once a sample has been converted into raw data and had segmentation maps associated with it, there are a number of different analyses that can be run against it. See Figure 3, below.

Figure 3: Analyses Categories and Tools

jsalvage, 05/07/12,

I am not sure how I feel about this being here. It seems like more of a design issue.

6

The analysis tools produce two different types of output when run on samples. The first output is raw data that can be used in statistical analysis. The second is a visualization of the results, which can take the form of a simple image or a graph. A sample visualization of a chord length distribution analysis can be seen in Figure 4.

Figure 4: Chord Length Distribution Visualization

7

3 REQUIREMENTS3.1 Use Cases

The use-cases depicted are organized into the following functional groups: account management, social collaboration, sample interaction, and analysis. Where applicable, screenshots of the proposed UI appears below the use case.

Figure 5: Account Management Use Cases

Use Case # UC-01Use Case Name Create Account

`Actors

Materials Engineering Researchers

Purpose To create a new user account for an actor.

Brief Description The system allows actors to create personal accounts for interaction with the system and other actors.

Flow of events The basic flow begins when an actor navigates to the account creation page.

1. The actor specifies basic account information: account name, password, and password confirmation.

2. The actor presses a submission button.3. The system redirects the actor to the login page, where a

success message is shown.4. An email will be sent to the new user welcoming them to

the service.Alternative flow of events 1. If the user’s account name already exists, the submission

button will reload the page. An error specifying that the

8

account name is already in use will be displayed.2. If the user enters a password confirmation that does not

match the initial password, the submission button will reload the same page. An error specifying that the passwords do not match will be displayed.

Pre-conditions None.

Post-conditions A new account with the provided information is created for the actor.

Special Requirements

Security: The system will display characters in the password fields as asterisks. The system will store passwords as one-way hashes.

Interface Mockup

Use Case # UC-02Use Case Name Login

Actors


Purpose To sign in to a personal account.

Brief Description The system allows actors to log in to personal accounts for interaction with the system and other actors.

Flow of events The basic flow begins when an actor navigates to the login page or any secure page while not logged in.

1. The actor specifies the account name2. The actor specifies the password3. The actor presses the submit button4. The actor is redirected to their home page or

whichever secure page they were attempting to

9

visit.Alternative flow of events

1. If the actor enters an incorrect password, the login screen is displayed with an error message stating the problem.

2. If the actor has more than three failed login attempts in a period of 15 minutes, the account becomes locked for one hour and cannot be accessed.

3. If the actor enters information for an account that does not exist, the login screen is displayed with an error message stating the problem.

Pre-conditions The account being logged into exists and the actor is not currently logged in.

Post-conditions The actor becomes logged in.


Security: The system will display characters in the password field as asterisks.

Interface Mockup

Use Case # UC-03Use Case Name Logout

Actors


Purpose To sign out of a personal account.

Brief Description The system allows actors to end their sessions by logging out.

Flow of events 1. The actor clicks the logout link located on every page.

2. The actor is logged out and redirected to the login page.

Alternative flow of events

None

Pre-conditions The actor is logged in.Post-conditions The actor becomes logged out.

10


None.

Interface Mockup

Use Case # UC-04Use Case Name Reset Password

Actors


Purpose To reset an account’s password

Brief Description The system allows for actors that forget their password to have a new password emailed to them.

Flow of events The basic flow begins when an actor navigates to the password reset page.

1. The actor enters the account name that needs to be reset

2. The actor presses a reset button3. The actor is redirected to the login page4. The actor is emailed a new password


1. If the account does not exist, the same flow of events occurs without a password being emailed.

Pre-conditions The account exists.

Post-conditions The specified account has a new password assigned to it and emailed to the actor.


Security: The system will randomly generate a password for the account each time the password is reset.

Interface Mockup

11

Figure 6: Social Collaboration Use Cases

Use Case # UC-05Use Case Name View Profile

Actors


Purpose To view a profile for a group or user.

Brief Description The system specifies a number of attributes related to groups and users that can be viewed by other users.

Flow of events The basic flow begins when an actor navigates to the profile page of a group or user.

1. The name is displayed2. The affiliation is displayed (if any)3. The location is displayed (if any)4. A short biography is displayed (if any)5. A list of interests is displayed (if any)


1. Attempting to view a profile page for a user or group that does not exist will not work.

Pre-conditions The user is logged in.

Post-conditions The requested profile page is displayed.

Special None

12

RequirementsInterface Mockups

Use Case # UC-06Use Case Name Edit Profile

Actors


Purpose To view a profile for a group or user.

Brief Description The system specifies a number of attributes related to groups and users that can be viewed by other users.

Flow of events The basic flow begins when an actor navigates to their own profile page.

1. The affiliation is displayed as editable2. The location is displayed as editable3. A short biography is displayed as editable4. A list of interests is displayed as editable5. The user edits any fields that they wish to change6. The user presses save changes


1. Attempting to edit a profile of another user does not work.

2. A user can edit the profile of any group that they administer through the same flow sequence.

Pre-conditions The user is logged in.

Post-conditions The profile page is edited.Special Requirements

None

13

Interface Mockup

Use Case # UC-07Use Case Name Follow user

Actors


Purpose To allow users to actively form a link to other users.

Brief Description The system allows users to follow each other, seeing any new posts to that user’s wall.

Flow of events The basic flow begins when an actor navigates to another user’s profile page that they are not already following.

1. The user clicks a button that reads ‘follow user’Alternative flow of events

1. Users are unable to follow themselves2. Users are unable to follow other users that they are

already following.Pre-conditions The user is logged in and not already following the target

user.

Post-conditions The user is set as following the target user.Special Requirements

None

Interface Mockup

14

Use Case # UC-08Use Case Name Unfollow user

Actors


Purpose To allow users to remove a follow link that associates them with other users.

Brief Description The system allows users to remove other users from their following list.

Flow of events The basic flow begins when an actor navigates to another user’s profile page that they are already following.

1. The user clicks a button that reads ‘unfollow user’Alternative flow of events

1. Users are unable to unfollow themselves2. Users are unable to unfollow other users that they

are not already following.Pre-conditions The user is logged in and already following the target user.

Post-conditions The user is set as not following the target user.Special Requirements

None

Interface Mockup

Use Case # UC-09Use Case Name View Wall

Actors


Purpose To allow actors to view messages posted to a user or group.

15

Brief Description The system associates a ‘wall’ with each user and group. The wall contains messages directed at the user or group it is associated with. Users can only post to another user’s wall if they are following that user.

Flow of events The basic flow begins when an actor navigates to another user’s wall page that they are already following.

1. All messages posted to the target’s wall are displayed in time order, with most recent coming first


1. Users are unable to see a post if they are not following the target user.

Pre-conditions The user is logged in and already following the target user.

Post-conditions None.Special Requirements

None

Interface Mockup

Use Case # UC-10Use Case Name Post to Wall

Actors


Purpose To allow actors to post messages to another group or user

Brief Description The system associates a ‘wall’ with each user and group. The wall contains messages directed at the user or group it is associated with. Users can only post to another user’s wall if they are following that user. Users can only post to a group’s wall if they have privileges within that group.

Flow of events The basic flow begins when an actor navigates to another user’s wall page that they are already following.

1. The user enters a message that they wish to post2. The user presses the post button


1. Users are unable to see a field to enter a message and post it if they are not already following the target user or have write access to a group.

16

Pre-conditions The user is logged in and already following the target user or has write access to a group.

Post-conditions The user’s message appears on the target user’s wall.Special Requirements

None

Interface Mockup

Use Case # UC-11Use Case Name Delete from Wall

Actors


Purpose To allow actors to remove their own messages or messages posted to their own wall.

Brief Description A user is allowed to remove a post at any time if one of two conditions are met: (1) the post is targeted at the current user or (2) the author of the post is the current user.

Flow of events The basic flow begins when an actor navigates to a wall page

1. The user presses the remove button next to the message they posted.


1. Users on their own wall are able to remove any message.

2. Users are unable to remove a message if they don’t own it or aren’t the recipient.

Pre-conditions The user looking at a wall to which they have posted a message.

Post-conditions The user’s message is removed from the target user’s wall.


None

Interface Mockup

17

Use Case # UC-12Use Case Name View Stream

Actors


Purpose To allow actors to view their stream

Brief Description The system associates a ‘stream’ with each user. The stream contains all messages posted to the people that the user is following, in reverse chronological order.

Flow of events The user navigates to their stream. All posts to people that they follow are displayed in reverse chronological order.


Users are unable to see a stream for another user.

Pre-conditions The user is logged in and already following at least one other user.

Post-conditions None.Special Requirements

None

Interface Mockup

Use Case # UC-13Use Case Name Search for User or Group

Actors


Purpose To allow actors to search for other users or groups.

Brief Description The system allows for users and groups to be searched by name.

Flow of events 1. The user enters a query into the search box found on every page

2. The user presses the search button3. A list of results is shown to the user, each of which

18

links to a profile page.Alternative flow of events

If no results are found, a message is displayed to the user.

Pre-conditions The user is logged in and searches for a userPost-conditions A list of results is displayed.Special Requirements

None

Interface Mockup

Use Case # UC-14Use Case Name Create Group

Actors


Purpose To allow actors to create groups to collaborate with each other.

Brief Description The system allows for users to form groups that share interests. User groups can be used to reach a collection of users at the same time.

Flow of events 1. The user navigates to the create a group page2. The user enters information about the group:

a. A unique nameb. A biographyc. A URLd. Research interests

3. The users presses the submit button4. The user is taken to the group’s profile page


If the group’s name is already in use, an error is displayed and the create group page is reloaded.

Pre-conditions The user is logged in.Post-conditions A group is created.Special Requirements

None

19

Interface Mockup

Use Case # UC-15Use Case Name Request Group Access

Actors


Purpose To allow actors to request access to a group

Brief Description The system allows users to request access to a group.

Flow of events 1. The user navigates to the group’s profile or wall.2. The user presses a button to request access to the

group.3. The administrators of the group are notified of the

request.Alternative flow of events

None

Pre-conditions The user is logged in.Post-conditions The group’s administrators are notified of the request.Special Requirements

None

Interface Mockup

20

Use Case # UC-16Use Case Name Set Group Privileges

Actors


Purpose To allow users to be accepted into a group or have their roles within a group changed.

Brief Description The system provides two different roles to a group: administrator and member. Administrators of a group are able to change a group’s profile, invite new members, set privileges, and post to the group’s wall. Members of a group are only able to post to a group’s wall. This use case allows a group’s administrator to specify the roles for members. Administrators can also use this to remove members from a group.

Flow of events 1. The user navigates to the group’s member administration page.

2. The user selects a member to modify.3. The user selects a role for the member.4. The user presses save.


If the user is not an administrator for a group, they cannot access the administration page.

Pre-conditions The user is logged in.Post-conditions The target user’s role within the group is set.Special Requirements

None

Interface Mockup

Use Case # UC-17Use Case Name Invite User to Group

Actors


Purpose To allow users to invite each other to groups.

Brief Description This allows for an administrator of a group to invite other

21

users into the group.

Flow of events 1. The user navigates to the group’s member administration page.

2. The user enters another user’s name into the invite box.

3. The user presses the submit button.4. The target user receives an invitation to the group.


If the user is not an administrator for a group, they cannot access the administration page.

Pre-conditions The user is logged in.Post-conditions The target user receives an invitation to the group.Special Requirements

None

Interface Mockup

Use Case # UC-18Use Case Name Accept Group Invitation

Actors


Purpose To allow users to accept or reject pending group invitations.

Brief Description This allows users to respond to invitations to join groups. Users can choose to accept or reject invitations on an individual basis.

Flow of events 1. The user navigates to their group invitations page.2. The user selects an invitation from a list of pending

invitations.3. The user presses the accept button.4. The user is added to the group’s member list and

the invitation is removed.Alternative flow of events

1. If the user presses the reject button instead of the accept button, they are not added to the group and the invitation is removed.

2. If the user has no pending invitations, the flow terminates at step 2.

Pre-conditions The user is logged in and has pending invitations.

22

Post-conditions The user is added to the group if the invitation is accepted. The invitation is deleted from the pending invitation list if it is rejected.


None

Interface Mockup

Use Case # UC-19Use Case Name Leave Group

Actors


Purpose To allow users to remove themselves from a group.

Brief Description This allows users to leave groups that they are no longer interested in.

Flow of events 1. The user navigates to the group’s profile page2. The user selects the leave group option.


1. If the user is not in the group, there is no leave option

Pre-conditions The user is logged in and is a part of a group.Post-conditions The user leaves the groupSpecial Requirements

None

Interface Mockup

23

Figure 7: Sample Interaction Use Cases

Use Case # UC-20Use Case Name Upload Sample

Actors


Purpose To allow users to add sample data to the system.

Brief Description This allows users to upload data of a supported data type to the system. There are three data types initially supported by the system: TIFF, ANG, and RAW. Due to the large size of these samples, users are also able to be notified via email when the upload process completes or fails.

Flow of events The flow of events starts when the user is on the upload sample page.

1. The user specifies which type of file they are uploading (TIFF, ANG, or RAW) and hits next.

2. The user selects the file that they are uploading.3. The user manually enters sample attributes based

on the input type and hits next.4. The user specifies whether they want to be emailed

the results of the upload when it finishes.5. The user hits submit to begin transferring data.6. Once the data is uploaded successfully, the user

receives an email if they requested notification.Alternative flow of events

1. If the user selects a file that does not match the type that they specified, the upload fails and an error message is displayed. If the user requested email notification, an email is also sent out explaining the problem.

2. If the upload process fails for any reason, a

24

message is displayed to the user. If the user requested notification, an email is also sent out that explains the problem.

3. The user can specify that they are uploading the sample on behalf of another user, giving that user ownership of the sample.

Pre-conditions The user is logged in.Post-conditions The sample and all associated attributes are added to the

system.Special Requirements

None

Interface Mockup

Use Case # UC-21Use Case Name Modify Sample

Actors


Purpose To allow users to alter the attributes of samples that they uploaded.

Brief Description This use case provides a means for a user to alter certain characteristics of a sample that they previously uploaded, in case a mistake was made or information was left out.

Flow of events The flow of events starts when the user is on the sample page.

1. The user clicks the edit button that appears next to the sample attributes.

25

2. The attribute fields become modifiable.3. The user makes changes to the fields.4. The user hits submit.5. The attribute fields are updated and switch back to

a read-only view.Alternative flow of events

1. If the user did not upload a sample that is being viewed, the edit button does not appear.

Pre-conditions The user is logged in and accessing a sample they uploaded.

Post-conditions The sample attributes are updatedSpecial Requirements

None

Interface Mockup

Use Case # UC-22Use Case Name Delete Sample

Actors


Purpose To allow users to delete samples that they have uploaded.

Brief Description This use case provides a means for a user to remove a sample that they have previously added to the system.

Flow of events The flow of events starts when the user is on the sample page.

1. The user clicks the delete sample button that appears on the page.

2. A prompt appears, asking the user to confirm the deletion.

3. The user confirms the deletion.4. The sample is removed from the system.

26


1. If the user did not upload a sample that is being viewed, the delete sample button does not appear.

2. If a user does not confirm the deletion, the sample remains in the system.

Pre-conditions The user is logged in and accessing a sample they uploaded.

Post-conditions The sample is deleted.Special Requirements

None

Interface Mockup

Use Case # UC-23Use Case Name View Sample

Actors


Purpose To allow users to view samples that they have access to.

Brief Description This use case provides a means for a user to view a sample that they have access to. Samples can be viewed as visualizations or downloaded as raw data. The types of available visualizations depend on whether the sample is 2D or 3D.

Flow of events The flow of events starts when the user is on the sample page that they have access to.

1. The user is presented with a visualization of the data

a. If the sample is 2D, the visualization is a single image

b. If the sample is 3D, there are two visualization modes: Paraview’s 3D rendering or multiple 2D slice images

2. The sample’s attributes are listed3. The links to a sample’s segmentation maps are

listed.4. A download link is visible on the page


1. If the user does not have access to a sample, an error message is displayed. Sample visualizations, attributes, and download links are not displayed.

27

2. If a user attempts to directly retrieve a sample they do not have access to through the sample’s download link, the download is not initialized.

Pre-conditions The user is logged in and accessing a sample.Post-conditions The sample’s information is shown.Special Requirements

None

Interface Mockup

Use Case # UC-24Use Case Name Share Sample

Actors


Purpose To allow users to specify access control levels for samples that they have uploaded.

Brief Description This use case allows users to share samples to facilitate collaboration. Samples can be made private and thus only visible to the owner. Samples can also be shared with individual groups or users. Finally, samples can be made fully public.

Flow of events The flow of events starts when the user is on the sample page that they own.

1. The user clicks on a share sample link2. The sample access control page is displayed3. The user selects a sharing model to use

a. Privateb. Selective sharing with individual users and

groupsc. Public

4. The user presses a save button.5. The users and groups specified are granted access

to a sample. All other users have their access revoked (if they were previously granted access).


1. If the user does not own a sample, the share sample link is not displayed.

28

Pre-conditions The user is logged in and accessing a sample that they own.

Post-conditions The sample is shared only with the users and groups specified


None

Interface Mockup

Use Case # UC-25Use Case Name Share Sample Segmentation Map

Actors


Purpose To allow users to associate segmentation maps with a sample.

Brief Description This use case allows users to upload segmentation maps that can be used to distinguish areas of interest within a sample. A sample can have any number of segmentation maps, each of which associates a phase or attribute with a specific color.

Flow of events The flow of events starts when the user is on the sample page that they own.

1. The user clicks on a link to upload a segmentation map

2. The upload segmentation map page is displayed3. The user selects an image file to upload4. The image is analyzed to determine which colors

are used5. If there are ten or less colors, the user is asked to

specify what each color means.6. The user clicks submit7. The segmentation data is associated with the

sampleAlternative flow of events

1. If there are more than ten colors in the segmentation map, individual color mappings do not need to be named.

2. If the user attempts to associate an image file that has different dimensions than the sample, the association fails and an error message is displayed.

29

Pre-conditions The user is logged in and accessing a sample that they have access to.

Post-conditions The segmentation data is associated with the sampleSpecial Requirements

None

Interface Mockup

Use Case # UC-26Use Case Name View Sample Segmentation Data

Actors


Purpose To allow users to see individual segmentation maps for a sample.

Brief Description This use case allows users to browse the segmentation maps for a sample. The sample is rendered in grayscale, with the colored segmentation map superimposed over it.


1. The user clicks on a link associated with a segmentation map for the sample.

2. The segmentation map is displayed as an image superimposed over a grayscale version of the sample visualization.

3. If the colors are mapped to individual phases, those mappings are listed.


1. If the sample has no segmentation data, there are no segmentation links that can be accessed.

2. If a user does not have access to a sample, they also do not have access to that sample’s segmentation maps.

Pre-conditions The user is logged in and accessing a sample that they have access to. The sample has at least one segmentation map associated with it.

Post-conditions The segmentation data is displayedSpecial Requirements

None

30

Interface Mockup

Figure 8: Sample Analysis Use Cases

Use Case # UC-27Use Case Name Run Analysis Tool

Actors


Purpose To allow users to run analysis tools on a sample

Brief Description This use case allows users to perform analyses on a sample. The available analyses are those built in to the system, which come from the following categories: feature extraction, Fourier representation, spatial analysis, spatial statistics, property simulation, processing simulation, and segment descriptors.

Initially, the system is planned to include two point statistics, chord length distribution analysis, MKS analysis, and RVE set analysis.


1. The user clicks on a link to access analyses for the sample

2. The user selects an analysis tool to run and presses next

3. The user provides any input required by the tool, such as a specific segmentation map or runtime parameters

4. The user is shown an estimated run time for the analysis tool

31

5. The user presses a begin button.6. When the analysis completes, the user is notified via

emaila. The email contains direct links to the results as

a visualization and as raw data b. The email will include the sample name

7. The analysis run is saved to the sample and visible to other users through the sample’s analysis page


1. If the analysis fails, the user is notified of the problem via email.

2. If a user does not have access to a sample, they also do not have access to analyses run against that sample

Pre-conditions The user is logged in and accessing a sample that they have access to.

Post-conditions An analysis tool is run against the sampleSpecial Requirements

None

Interface Mockup

3.2 Requirements PrioritizationPriority

Description

1 Requirements with this priority must be implemented and verified prior to release.

2 Requirements with this priority should be implemented and verified for the release if time permits.

3 Requirements with this priority should be considered for future releases.

3.3 Functional RequirementsThe following lists detail the requirements for the web front-end of the Hephaestus system.

32

3.3.1 Account Management Requirements3.3.1.1 Users can create an account consisting of a user name (a valid

email address) and password. Priority 1

3.3.1.1.1 A verification email will be sent to the new user containing a welcome message, their user name, and a link to the service. Priority 2

3.3.1.1.2 Users have unique user names. The system rejects and notifies the user when a trying to create an account that is not unique.

3.3.1.2 Users must log in, providing a valid user name and password combination, in order to access the system. Priority 1

3.3.1.2.1 Users that enter an invalid user name and password combination are shown an error message indicating the problem. Priority 1

3.3.1.2.2 Users that enter the wrong information three consecutive times within a fifteen minute period will become locked out of the account for one hour. Priority 3

3.3.1.3 Users are able to log out at any time to end their session. Priority 1

3.3.1.4 Users can choose to reset their account password to a randomly generated one that is emailed to them. Priority 1

3.3.2 Social Collaboration Requirements 3.3.2.1 Users can form groups. Priority 1

3.3.2.1.1 Groups have unique names that are not modifiable. The system rejects and notifies the user when a trying to create an account that is not unique.

3.3.2.1.2 Groups have a profile consisting of a text biography, website URL, and list of research interests.

3.3.2.1.3 Groups have a wall that contains messages for the group.

3.3.2.1.4 Members of a group are assigned a role of either administrator or member. Administrator users are able to invite new members, modify a group’s profile, accept membership requests, remove members, and promote other

33

members to an administrator role. Administrators and members of a group are able to view and submit messages to the group’s wall.

3.3.2.1.5 Users can request an access to a group.

3.3.2.1.6 Users can accept or reject an invitation to a group.

3.3.2.1.7 Users can leave groups.

3.3.2.2 Users have a list of users that they are following. Priority 1

3.3.2.2.1 Users can add other users to the list of users that they are following.

3.3.2.2.2 Users can remove other users from their follow list.

3.3.2.3 Users have a wall that contains messages to that user. Priority 1

3.3.2.3.1 Users can post messages to their own walls.

3.3.2.3.2 Users can see other users’ walls, if they are following that user.

3.3.2.3.3 Users can post messages to other users’ walls, if they are following that user.

3.3.2.3.4 Users can delete messages that are on their own walls.

3.3.2.3.5 Users can delete messages that they send.

3.3.2.4 Users have a public profile. Priority 1

3.3.2.4.1 Users can optionally share their affiliation.

3.3.2.4.2 Users can optionally share their location.

3.3.2.4.3 Users can optionally share a short biography about themselves.

3.3.2.4.4 Users can optionally share a website URL.

3.3.2.4.5 Users can optionally share a list of their research interests.

34

3.3.2.5 Users can see an aggregate list of messages posted to all of the other users that they are following, organized in reverse chronological order. Priority 2

3.3.2.6 Users can search for other users and groups by name. Priority 1

3.3.2.6.1 Search link to the target’s public profile.

35

3.3.3 Sample Interaction Requirements

3.3.3.1 The user can select a file of a supported type and upload it to the system. Priority 1

3.3.3.1.1 The system accepts files in the TIFF format. Priority 1

3.3.3.1.2 The system accepts files in the ANG format. Priority 2

3.3.3.1.3 The system accepts files in the RAW format. Priority 1

3.3.3.1.4 The system rejects unrecognizable files and notifies the uploading user. Priority 1

3.3.3.1.5 The user can opt to receive an email notification when the upload completes or fails. Priority 1

3.3.3.2 The user can modify the attributes of samples that they have uploaded to the system. Priority 1

3.3.3.3 The user can delete samples that they have uploaded from the system. Priority 1

3.3.3.3.1 The user must confirm the deletion before the sample is removed.

3.3.3.4 The user can view data samples that they have uploaded or have been granted access to. Priority 1

3.3.3.4.1 For 2D samples, the user can view the data as a single visualization. Priority 2

3.3.3.4.2 For 3D samples, the user can view the data as multiple 2D slice visualizations. Priority 2

3.3.3.4.3 For 3D samples, the user can view the data as Paraview models. Priority 2

3.3.3.4.4 The user can download data samples that they have uploaded or have been granted access to.

3.3.3.5 The user can specify access control levels for any samples that they have uploaded. Priority 1

3.3.3.5.1 By default, samples are private. Only the uploader of the sample can access it.

3.3.3.5.2 Samples can be shared with individual users.

36

3.3.3.5.3 Samples can be shared with groups of users.

3.3.3.5.4 Samples can be made public and accessible by every user.

3.3.3.6 The user can upload segmentation data for a sample they have access to. Priority 1

3.3.3.6.1 The user can specify which colors of a segmentation map correspond to each phase as long as there are ten or less colors.

3.3.3.6.2 A sample can have any number of segmentation maps associated with it.

3.3.3.6.3 A segmentation map can only be associated with a sample if they share the same dimensions.

3.3.3.7 The user can view the segmentation data for any sample they have access to. Priority 1

3.3.3.8 The user can search for samples based on name or attributes. Priority 1

3.3.4 Analysis Requirements

3.3.4.1 The system supports analysis tools that can be run on samples. Priority 1

3.3.4.1.1 The system has two point statistics analysis built in. Priority 1

3.3.4.1.2 The system has chord length distribution analysis built in. Priority 1

3.3.4.1.3 The system has RVE set analysis built in. Priority 2

3.3.4.1.4 The system has MKS analysis built in. Priority 2

3.3.4.1.5 The system supports at least one tool from each of the seven categories listed in section 2.3. Priority 3

3.3.4.2 The user can run analysis tools on any data samples that they have uploaded or been granted access to. Priority 1

3.3.4.2.1 When applicable, the user can specify parameters to be passed to the analysis tool. Priority 1

3.3.4.2.2 When applicable, the user can specify a specific sample segmentation to run the tool against. Priority 1

37

3.3.4.2.3 When selecting an analysis tool to run, the user is shown an estimated time until completion. Priority 2

3.3.4.2.4 When an analysis is complete, the user will be notified of completion via email. The email will contain the sample name, analysis type, and a link to the results. Priority 1

3.3.4.2.5 Analysis results can be downloaded as raw data. Priority 1

3.3.4.2.6 Analysis results can be viewed as a visualization appropriate to the tool used. Priority 1

38

3.4 Non-Functional Requirements3.4.1 Acceptance Constraints

3.4.1.1 All priority 1 functionality will be in the system by May 8th, 2012 to meet external deadlines.

3.4.2 Software Constraints

3.4.2.1 The system accepts samples of up to 20 GB in size.

3.4.2.2 The system stores user passwords as salted hash values.

3.4.2.3 The system displays passwords as asterisk strings.

3.4.2.4 The system provides a plugin architecture to add new analysis tools.

3.4.3 Software Interface Constraints

3.4.3.1 The system interfaces with a remote MATLAB server.

3.4.3.2 The system exposes its account management and sample handling functionality through the SOAP protocol.

3.4.3.2.1 All functionality available through SOAP, except creating accounts and logging in, requires authorization.

39

3.5 User Interface RequirementsHephaestus contains pages within three categories: the social network, sample viewing, and sample uploading. A transition diagram can be seen below.

Figure 9: UI Transition Diagram

In the above diagram, some of the boxes are bolded and underlined. Those represent categories of pages, instead of individual pages. All children of a category have a transition to their siblings. As an example, within the Groups category, there are Profile, Wall, and Administration. Each of those pages has a link to each other page.

In the case of nested groups, all children of the nested group also have access to the siblings of the outer group. An example can be seen in the Groups category, which is a child of the Social Network category. The group Profile, Wall, and Administration pages all have access to the social network’s Search page.

Sample screenshots and mockups of the above pages can be seen within the associated use case tables.

40

4 SYSTEM EVOLUTIONThe future of this system is expected to include support for visualization of analysis results and a more varied library of analysis techniques. Furthermore, the system is expected to have more than four categories of analysis tools and is expected to have more than one tool per category. The social networking aspects of the system will be expanded to be more attractive and entice regular usage. The repertoire of recognized data formats will grow to ease the workload of the users producing the samples.

5 REFERENCES[1] http://www.whitehouse.gov/blog/2011/06/24/materials-genome-initiative-renaissance-american-manufacturing

hephaestus requirements - cs. web viewmatlab. a tool and ... they must rely on word of mouth,...

Documents