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
1
| 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
2
| 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
3
| 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
4
| 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
1
Availability is also known as robustness.
2
Adaptability is also known as evolvability, plugability and upgradeability.
3
Configurability is also known as customizability, extensibility and flexibility.
4
Maintainability is also known as serviceability.
About the author
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.
Comments (Undergoing maintenance)
Back to top
Trademarks | My developerWorks terms and conditions
Help: Update or add to My dW interests
What's this?
This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.
And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.
View your My developerWorks profile
Return from help
static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=87672
ArticleTitle=Appendix B: Architectural Requirements
publish-date=04302004
author1-email=dwinfo@us.ibm.com
author1-email-cc=
