Addressbook (component)

From UG

Contents 1 General Info and Scope 1.1 Scope 2 Business Requirements 3 Notes from Systems Architect 4 Rapid Design 4.1 Address Profile Fields 4.1.1 Company City 4.1.2 Remark 4.1.3 Address 1 4.1.4 Address 2 4.1.5 Address 3 4.1.6 City 4.1.7 Zip 4.1.8 Country 4.1.9 State 4.1.10 Contact Person 4.1.11 Tel 4.1.12 Fax 5 Detailed Design 5.1 Summary 5.2 User Interface 5.3 Functionality / Use Cases 5.4 Special Cases and Misc 6 QA 6.1 Test Cases 7 Look and Feel 8 Figures 8.1 Figure 1: 9 Misc 9.1 Link to User Guide 9.2 Questions 9.3 Request For Comments (Suggestions and Ideas) 9.4 Known Non Critical Bugs 9.5 Implementation: Link To DB 9.6 Implementation: Link To Front End Code 9.7 Implementation: Link To Back End Code 10 History 10.1 m901

General Info and Scope

• Classified As: (small) (large) component / common feature / misc
• Parent Mantis: tbd
• Prerequisites: any articles that must be read before to understand this?

Scope

• List what it covers and what it does not

Business Requirements

• This section is defined by Business Analyst
• In this section this component/feature is defined from the business standpoint. All important points are listed. It could include some design details if business insists on specific design.

Notes from Systems Architect

• This section is defined by Systems Architect. It is written after #Business Requirements are defined.
• The purpose of this section is to give direction to System Analysts who will write detailed specification.

Rapid Design

• In some cases (component is non standard) we need to do preliminary not so detailed design before detailed final. And maybe even code it to create Prototype
• This section does not have to be too detailed or too formalized. We shall not spend too much time on Prototypes - they can change many times.

Address Profile Fields

Company City

Remark

Address 1

Address 2

Address 3

City

Zip

Country

State

Contact Person

Tel

Fax

Detailed Design

• This section is defined by Systems Analyst.
• It contains detailed technical design is written after #Business Requirements and #Technical Requirements are defined.

Summary

User Interface

Functionality / Use Cases

• This section you could spit into two. But often it is hard to do since often most of functionality is UI related

Special Cases and Misc

• If any exist

QA

This section is to be written by QA Engineer or QA Manager or Systems Analyst.

Test Cases

• List unusual scenarios - things that user most of the time would not do but system must handle well
• Do not list Common Test Cases - link to them

Look and Feel

• This section is to be written / defined by Graphic Designer and UI Designer.
• This includes: final graphics, final layout
• Layout defined here should refine, provide more detials to "functional definitions" of UI as defined in #User Interface and Functionality section above

Figures

Figure 1:

Misc

Link to User Guide

Questions

Request For Comments (Suggestions and Ideas)

Known Non Critical Bugs

• Critical bugs must be posted into Mantis

Implementation: Link To DB

Implementation: Link To Front End Code

Implementation: Link To Back End Code

History

m901

• (*ph1)(Admin AddrBook) Re-design: Address Profile should include all categories: Transportation, Vendors, Bill To