Software Requirements Specification Version 1.0 Team 3 Creation Station

Transcription

1 Software Requirements Specification Version 1.0 Team 3 Creation Station Introduction 1.1 Purpose of the Document The purpose of this document is to define generally and specifically the requirements of the software being created for One Great Family. One Great Family is a company providing software services for family history seekers. One Great Family provides users with the unique feature of building their family trees for them. One Great Family has specified two areas where we could be of assistance. First, they asked us to build a graphical representation of the relationship between two people. Their system can find some relationship between almost any two people, but usually it is quite obscure (i.e. 5 th cousins, twice removed). The task is to design and implement a good way to visually represent these relationships. 1.2 Scope of the Development Project One Great Family said they expect that completing this first task will be plenty of work for the scope of this project, and have offered a second task in the even that they overestimated the amount of time it will take to complete it. Currently users are presented with their family trees in a way that is not as appealing as One Great Family thinks it could be. The second task is to find a good way to represent a family tree to the user. 1.3 Definitions, Acronyms and Abbreviations AJAX Asynchronous Javascript and XML CSS Cascading Style Sheets OGF One Great Family, used when referring to the company name OGFN One Great Family Number, a unique identify for each family member ZID The old term used as a unique identifier. This term is deprecated, but will still come up in older code. Now use OGFN

2 1.4 References None available at this time. 1.5 Overview of Document The rest of this document will more specifically describe the software to be created, giving clear examples that illustrate the problem to be solved. Specific requirements will also be laid out. 2. General Description 2.1 User Personas and Characteristics Persona 1. Name: James Halls Age: 40 Occupation: Sales Hobbies: Geneaology, buying collectables on Ebay Persona 2. James uses the software for fun. He is interested in geneology and has been tracking his own family history through physical records. However, since he became interested in computers several years ago, he has realized that there is a much easier way to do his investigation. James is somewhat sophisticated end-user. He is interested in collecting vintage goods on Ebay, so he is able to upload pictures, fill out registration forms, move files around his hard drive, etc. James has tried several online geneology applications, but each has failed him in some way. Either they are too time-cosuming to use, or their information is not accurate enough. Name: Jewel Burges Age: 57 Occupation: Elementary school teacher Hobbies: Arts and Crafts, genelogly

3 Jewel became interested in geneology about a year ago when she needed to teach a segment on it for her 7 th grade class. In her research, she found that she needed to use a computer. She was new to computers, although her kids had gotten her one a couple of years ago. She really never had a use for it, and therefore never used it. However, now her renewed interest has been sparked by her interest in geneology. Her skills are weak, and often relies on her children or grandchildren to install software, or maintain her affairs on the machine. 2.2 Product Perspective This product is intended to be used alongside One Great Family s (OGF) main desktop application. Since this application is web-based, users may start it alone, but when they need more information on a particular person, they have the option of launching the desktop application from the web-app. 2.3 Overview of Functional Requirements The functions of the Relationship Calculator may be divided into two sections. In the first, users can put the names of two individuals into two form fields, and what is returned to them is a Generation View. This gives the user and easy-to-understand structure that explains how one user may be related to another, for example, 3 rd cousin twice removed. The second section is another view, known as the Begat View. This is the more traditional pedigree style view, running from left to right, in the form of a tree. Users may input an amount of time they wish to wait, as well as how many generations they wish to see. When this view arrives, users will be able to zoom in and out. At higher views, the individuals are marked as colored boxes. The colors represent relationships. As the view gets closer, more information is displayed from each box. This information includes the individuals full name, birth date, and birth place. When a user does a mouse-over on one of the boxes, additional information appears. This information may include a picture, death date, death place, and

4 OFGN (a unique id for users in the One Great Family system. If users click on the box, the desktop application will launch. Besides, zooming, users will be able grab the chart with their mouse, and move it in any direction to see parts that are outside the view of the browser window. 2.4 Overview of Data Requirements Data is a simple affair for the user. They only need fill in two text-boxes, into which the names of the persons to be calculated are placed. All other data is stored on OGF servers and delivered to the browser as needed. 2.5 General Constraints, Assumptions, Dependencies, Guidelines The Relationship calculator must be web-based. Moreover, it must be able to run in popular web browsers such as Internet Explorer, Mozilla, Netscape, and Safari. Care must be taken to ensure that the chart is no bigger than 100k at any point in time. 2.5 User View of Product Use If the persona James is using the application, he may have multiple other applications running at the same time. His web browser may be re-sized to sit in one corner of his monitor so that he can see these other applications. However, when focuses his attention on the application in question, he has the ability to resize his windows and browser size so that the application has maximum screen space. He is able to use key commands if available, and may have multiple instances of the application open at one time. If the user Jewel is using the application, the web browser will be displayed at whatever resolution is was last set. Advanced features may be overlooked, and for her to see the main features, they need to be clearly labeled. In addition, if she needs help for any item, it must be readily available to her.

5 When she is shown how to use the software one time, there is a good chance that is the only way she will use the software, unwilling or unable to explore other options. 3. Specific Requirements 3.1 External Interface Requirements OGF s Relationship Calculator needs a web page to be able to display anscestor relationships in a graphical manner using some type of chart. The chart should show the person the relationship is calculated from, along with the person the relationship is calculated to and all the ancestors in between. 3.2 Template for describing functional requirements Requirement: A description of the functional requirement. Input: web page user input. Processing: web page processing. Output: new page display. Input: Processing: Output: Etc Requirement: Ancestor list web page. Input: Starting and ending ancestors. Generation limiter control to allow the user to choose how many generations to display at a time. Processing: The starting and ending ancestor info will be sent to the OGF API and the required data to display the charts will be returned. We will need to dynamically create the web page from the returned data. Output: Chart display of list of ancestors in between the starting and ending ancestor. If the relationship cannot be calculated within the specified number of generations then do something appropriate. (to be determined).

6 Requirement: The chart in item should contain a box for each person in the relationship. Each box should contain the ancestor s full name, birth date and birth place. There should be lines connecting the ancestor boxes showing the route of the relationship. Input: User can mouse over the ancestor list boxes to get additional information. Processing: A new box will be created on mouse over that shows the full name, birth date and birth place of the ancestor along with his/her picture, death date, death place and One Great Family Number (OGFN). Output: Overlay the new box over the existing web page. Input: User clicks on the ancestor box. Processing: Redirect to the Once Great Family browser web page with the selected ancestor in view. Output: See processing. Requirement: The user should be able to zoom in and zoom out on the chart in item Input: There should be controls on the page that show how far the user is zoomed in and give the user options to zoom in, zoom out, or reset to default view. Processing: Create the chart at the next or previous level of detail. Note that it is unclear at this point whether we should do this at zoom time or if we need to pre-build all the charts in advance at each level. Output: The chart should zoom in or zoom out to the appropriate level of data detail and display a new chart. Requirement: The user should be able to move around(browse) the chart in item Input: The user should be able to move around the chart vertically, horizontally and diagonally. Additionally, the user should be able to move the chart by clicking on it and dragging. There should be a mechanism to reset the view to the default. Processing: Create the new window view of the chart. Note that it is unclear at this point if this should be done at browse time or if the entire chart should be created in advance. Output: The chart should smoothly scroll to the new window view of the chart.

7 3.2 Performance Requirements Charts should be no larger than 100k in size at any given time. If this is not possible, then some type of loading indicator should be present on the screen. All web pages should be viewable within 770 x 400 pixels. Any images used in the charts should be in a compressed graphic format. 3.3 Quality Attributes It should be easy to change the color scheme of the chart boxes whether they are images or in a CSS file. If CSS is used in the charts it should be broken out into logical classes representing the different objects on the page. In-Line(within page) style should be used rarely, if at all, to make the page easily updatable, CCS should be used in most cases where style is required. All code should be well documented with comments describing each method s parameters, functionality and return results. Code should be broken up into logical blocks, with each block having a comment as to what task it is currently performing. Naming abbreviations should be used rarely. All variable, classes and methods should be given full names that easily represent the functions they perform. Any methods that accept more than six parameters should use an object as a parameter rather than a list of parameters. 3.4 Other Requirements None at this time.