The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

All information submitted is secure.

My developerWorks:

My notifications:

Sign out

Select a language:

Appendix B: Architectural Requirements

Peter Eeles, Senior IT Architect, IBM, Software Group

Peter Eeles has over 15 years experience developing software solutions, and has spent the majority of this time architecting and implementing large-scale distributed systems, culminating in the writing of his first book entitled Building Business Objects (John Wiley and Sons). Peter works as a Process Consultant for IBM Rational (UK), and is the Rational Architecture Practice representative for Northern Europe. In his spare time, Peter enjoys bike racing and playing jazz guitar, although not at the same time.

Summary: from The Rational Edge: Appendix B for the article "Capturing Architectural Requirements," at http://www-128.ibm.com/developerworks/rational/library/4706.html

Date: 30 Apr 2004
Level: Introductory

Activity: 10988 views
Comments:

From "Capturing Architectural Requirements"

This appendix summarizes the architectural requirements to consider.

Functionality

Functional requirements that are of particular relevance to architecture are generally derived from the analysis mechanisms listed in Appendix A.

Usability

Requirement	Description
Accessibility	The ease with which different facets of the system are exercised.
Aesthetics	The aesthetic quality of the user interface.
Consistency	The consistent use of mechanisms employed in the user interface. This applies both within the system, and with other systems.

Reliability

Requirement	Description
Accuracy	The accuracy of any calculations performed.
Availability ¹	The amount of system "up time."
Recoverability	The elegance with which the system recovers from failure.

Performance

Requirement	Description
Recovery time	The time to recover from a system failure.
Response time	The time for the system to provide a response.
Shutdown time	The time for the system to shut down.
Start-up time	The time for the system to start up.
Throughput	The capacity of the system to support a given flow of information.

Supportability

Requirement	Description
Adaptability ²	The ease with which the system is adapted to new environments.
Auditability	The ease with which the system provides audit trails of its execution.
Compatibility	The compatibility of this system with previous versions of the system.
Configurability ³	The ease with which the system is configured.
Installability	The ease with which the system is installed.
Localizability	The level to which the system supports multiple human languages.
Maintainability ⁴	The ease with which the system is maintained.
Scalability	The ease with which the system can scale in terms of data volumes and users.
Testability	The ease with which the system is tested.

Design Requirement

A design requirement is simply a constraint on the refinement of an analysis mechanism, such as those listed in Appendix A. For example, a requirement for a relational database is a constraint on the refinement of a persistence analysis mechanism. The set of design requirements to consider is therefore derived directly from the list of analysis mechanisms.

Implementation Requirement

Requirement	Description
Third-party components	Any constraints on the use and cost of third-party components.
Implementation languages	The implementation languages to be used.
Platform support	The platforms that the system will support.
Resource limits	Limits on the use of resources such as memory and hard disk space.
Standards compliance	Any standards to which the system must conform.

Interface Requirement

Requirement	Description
External systems	External systems with which this system must interface.
Interface formats	The format of any data passed between this system and external systems.

Physical Requirement

Requirement	Description
Shape	The shape of the resulting hardware housing the system.
Size	The size of the hardware housing the system.
Weight	The weight of the hardware housing the system.

Footnotes

¹ Availability is also known as robustness.

² Adaptability is also known as evolvability, plugability and upgradeability.

³ Configurability is also known as customizability, extensibility and flexibility.

⁴ Maintainability is also known as serviceability.

About the author

Close [x]

Report abuse help

Report abuse

Thank you. This entry has been flagged for moderator attention.

Close [x]

Report abuse help

Report abuse

Report abuse submission failed. Please try again later.

Close [x]

developerWorks: Sign in

All information submitted is secure.

Close [x]

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.