Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

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.

  • Close [x]

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.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

Appendix C: Sample Architectural Requirements Questionnaire

Peter Eeles, Senior IT Architect, IBM, Software Group
Author Photo

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 C for the article "Capturing Architectural Requirements," at http://www-128.ibm.com/developerworks/rational/library/4706.html

Date:  30 Apr 2004
Level:  Introductory

Activity:  16951 views
Comments:  

From "Capturing Architectural Requirements"

This section contains a sample Architectural Requirements Questionnaire. The examples shown here exclude the answer and priority columns, which are discussed in the main body of my article.

This questionnaire also groups together related items that were previously categorized in separate sections. Consider all aspects of auditing, for example. Auditing manifests itself as a functionality requirement (Is audit capability required?), supportability requirement (What level of auditing is needed?) and design requirement (Are there any design constraints on the mechanism used to provide audit capability?). Such requirements tend to be related to particular analysis mechanisms and are therefore grouped together in the "Analysis Mechanisms" section.


Analysis Mechanisms
Requirement Questions Impact

Auditing

Functionality

Supportability

Design requirement

;

Is audit capability required?

What level of auditing is needed?

Are there any constraints on the mechanism used to provide audit capability?

The greater the sophistication of the audit mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Authentication

Functionality


Design requirement

;

Is there any requirement for authentication?

Are there any constraints on the mechanism used to provide authentication capability?

The greater the sophistication of the authentication mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Communication

Functionality


Design requirement

;

Will inter-process communication be required?

Are there any constraints on the mechanism used to provide communication capability?

The greater the sophistication of the communication mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Error management

Design requirement

;


Are there any constraints on the mechanism used to provide error management capability?
The greater the sophistication of the error management mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Event management

Design requirement

;


Are there any constraints on the mechanism used to provide event management capability?
The greater the sophistication of the event management mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Licensing

Functionality


Design requirement

;

Will the system, or parts of the system, be licensed?

Are there any constraints on the mechanism used to provide licensing capability?

The greater the sophistication of the licensing mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Localization

Functionality


Supportability


Design requirement

;

Does the system need to support multiple human languages?

Which human languages need to be supported?

Are there any constraints on the mechanism used to provide localization capability?

The greater the sophistication of the localization mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Online help

Functionality

Design requirement

;

Will online help be required?

Are there any constraints on the mechanism used to provide online help?

The greater the sophistication of the online help mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Persistence

Functionality

;

;

;

Design requirement

;

Will data manipulated by the system be written to disk? Are both shared persistent data and user-specific persistent data required?
Will shared persistent data need to be made available to a "traveling" user who is working offline?

Are there any constraints on the mechanism used to provide persistence?

The greater the sophistication of the persistence mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Printing

Functionality

Design requirement

;

Is printing capability required?

Are there any constraints on the mechanism used to provide printing capability?

The greater the sophistication of the printing mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Reporting

Functionality

Design requirement

;

Is reporting capability required?

Are there any constraints on the mechanism used to provide reporting capability?

The greater the sophistication of the reporting mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Scheduling

Functionality


Design requirement

;

Will certain system actions need to be scheduled?

Are there any constraints on the mechanism used to provide scheduling capability?

The greater the sophistication of the scheduling mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Security

Functionality


Design requirement

;

Will elements of the system need to be secure?

Are there any constraints on the mechanism used to provide security capability?

The greater the sophistication of the security mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Transaction management

Functionality


Design requirement

;


Will transactional capability be required?

Are there any constraints on the mechanism used to provide transactional capability?

The greater the sophistication of the transaction management mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Workflow

Functionality


Design requirement

;

Will movement of organizational units of work be required?

Are there any constraints on the mechanism used to provide workflow capability?

The greater the sophistication of the workflow mechanism, the longer the time to market, and the greater the long-term maintenance cost.

Functionality

All functional requirements are addressed in the "Analysis Mechanisms" section above.


Usability
Requirement Questions Impact
Accessibility Are there any special requirements that relate to the ease with which the system can be exercised (including by novice users)?The greater the accessibility, the longer the time to market, and the greater the long-term maintenance cost.
Aesthetics Are there any special requirements regarding the "look and feel" of the system?The greater the aesthetic appeal, the longer the time to market.
Consistency Are there any special requirements regarding the consistency of the user interface, both within the system and with other systems?The greater the level of consistency, the longer the time to market.

Reliability
Requirement Questions Impact
Accuracy Are there particular constraints on the accuracy of any calculations to be performed by the system?The greater the level of accuracy, the longer the time to market.
Availability Are there any requirements regarding system "up time"? This may be specified in terms of Mean Time Between Failures.The higher the availability, the longer the time to market.
Recoverability Are there any special requirements regarding recovery from a system failure?The greater the level of recoverability, the longer the time to market.

Performance
Requirement Questions Impact
Recovery time Are there any requirements on the time the system takes to recover from a system failure?The shorter the recovery time, the more sophisticated the recovery mechanism and the longer the time to market.
Response time Are there any constraints on the time the system takes to respond to particular events, such as user interaction?The shorter the response time, the longer the time to market.
Shutdown time Are there any requirements on the time the system takes to shut down?The shorter the shutdown time, the more sophisticated the shutdown mechanism and the longer the time to market.
Start-up time Are there any requirements on the time it takes the system to start up?The shorter the start-up time, the more sophisticated the start-up mechanism and the longer the time to market.
Throughput Are there any special requirements regarding throughput of data supported by the system? The greater the throughput of data, the longer the time to market.

Supportability
Requirement Questions Impact
Adaptability Are there any special requirements regarding adaptation of the software (including upgrading)?The greater the system's adaptability, the longer the time to market, and the greater the long-term maintenance cost.
Compatibility Are there any requirements regarding this system and its compatibility with previous versions of this system or legacy systems providing the same capability? The greater the compatibility, the longer the time to market.
Configurability Will the product be configured after it has been deployed? In what way will the system be configured? The greater the configurability of the system, the longer the time to market, and the greater the long-term maintenance cost.
Installability Are there any special requirements regarding system installation?The greater the installability of the system, the longer the time to market.
Maintainability Are there any special requirements regarding system maintenance?The greater the maintainability of the system, the longer the time to market. The trade-off is between time to market of the first release of the system, and any subsequent releases.
Scalability What volumes of users and data will the system support? This may be expressed as a profile over time.The greater the scalability of the system, the longer the time to market.
Testability Are there any special requirements regarding the testability of the system, such as testing "hooks" that allow integration with a testing tool?The greater the testability of the system, the longer the time to market.

Design Requirement

All design requirements are addressed in the "Analysis Mechanisms" section above.


Implementation Requirement
Requirement Questions Impact
Third-party components Are there any constraints (including cost) on the use of third-party components in the system?

How important is it for the system to be vendor independent, in terms of the third-party components it uses?

Are there any approved relevant alliances with third- party vendors?
The more third-party components used, the shorter the time to market. Also, the system is likely to be more maintainable because these components are effectively subcontracted.

Existing alliances typically remove the need for contractual negotiations, thereby improving time to market.
Implementation languages Are there any constraints on the programming languages used to develop the system?Specification of particular programming languages must be reconciled with tool support and available skills. Time to market is increased if either tools or skills are unavailable.
Platform support What platforms must the system support? Which operating system versions must be supported?

Is Web access required? If so, then which Web browsers and versions must be supported?

Will the system be ported to new platforms in the future (over and above those explicitly stated for the system)?
Development for a single platform shortens the time to market. It also allows closer integration with platform features.

Development for multiple platforms lengthens the time to market. Close integration with platform features is lessened, increasing system maintenance. However, deployment on new platforms is quicker.
Resource limits Are there any limits on the use of system resources, such as memory or hard disk space?The more constrained the available resources, the more efficient resource use is required. This increases time to market and lessens maintainability.
Standards compliance Are there any standards to which the system must conform? This may include coding standards or a user interface style guide.Use of available standards can decrease time to market and improve consistency in a number of system areas.

Interface Requirement
Requirement Questions Impact
External systems Are there any external systems with which this system must interface? Consider both provided and required interfaces.The greater the sophistication of the interface to external systems, the longer the time to market, and the greater the long-term maintenance cost.
Interface formats Are there any constraints on the nature of the interface between this system and any external system, such as the format of data passed between these systems, and any particular protocol used? The greater the sophistication of the format of interfaces, the longer the time to market, and the greater the long-term maintenance cost.

Physical Requirement
Requirement Questions Impact
Shape Are there any constraints on the shape of the hardware used to house the resulting system?Constraints on the shape of the hardware may impose a specification of physical devices required by the system, such as storage devices or printers. The more constrained the hardware, the longer the time to market.
Size Are there any constraints on the size of the hardware used to house the resulting system? Constraints on the size of the hardware may impose a specification of physical devices required by the system, such as storage devices or printers. The more constrained the hardware, the longer the time to market.
Weight Are there any constraints on the weight of the hardware used to house the resulting system?Constraints on the weight of the hardware may impose a specification of physical devices required by the system, such as storage devices or printers. The more constrained the hardware, the longer the time to market.

About the author

Author Photo

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.

Report abuse help

Report abuse

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


Report abuse help

Report abuse

Report abuse submission failed. Please try again later.


developerWorks: Sign in


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


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.

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.

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


Rate this article

Comments

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=87625
ArticleTitle=Appendix C: Sample Architectural Requirements Questionnaire
publish-date=04302004
author1-email=dwinfo@us.ibm.com
author1-email-cc=