Operational Requirements


Published on


An overview of Operational Requirements, as used for a lightning talk at Columbus Architects Group (colarc.org).

Much of this material is based on material from the book "MCSD .NET Solution Architectures" by Randy Cornish, Thomas Moore, Don Pavoni and Eric Rockenbach

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Hi everybody! I wanted to put together some kind of Architects 101 type talk, so I’ve decided to focus on one aspect of Requirements Analysis: Operational Requirements. I thought this might be a good starter topic, as getting these right will help you build a reliable system.
  • Operational Requirements

    1. 1. Operational Requirements Greg Malcolm – Mar 2 2009 Columbus Architecture Group Twitter: gregmalcolm [email_address] Blog: http://geekswithblogs.net/gregorymalcolm
    2. 2. Operational Requirements <ul><li>PASS MADE: </li></ul>A list of major Operational Requirement types: <ul><li>P erformance </li></ul><ul><li>A vailability </li></ul><ul><li>S ecurity </li></ul><ul><li>S calability </li></ul><ul><li>M aintainability </li></ul><ul><li>A ccessibility </li></ul><ul><li>D eployment </li></ul><ul><li>E xtensibility </li></ul>(&quot;PASS MADE&quot; concept comes courtesy of Randy Cornish et al, “MCSD .NET Solution Architectures “)
    3. 3. P ASS MADE <ul><li>Performance Requirements </li></ul><ul><li>Traditionally more of an issue for web based applications. </li></ul><ul><li>Mostly applies to Response Time: </li></ul><ul><ul><li>Limited Bandwidth </li></ul></ul><ul><ul><li>Server or network capacity </li></ul></ul><ul><ul><li>Server traffic </li></ul></ul><ul><ul><li>Application processing constraints </li></ul></ul><ul><li>Many of these factors will be beyond your control. </li></ul><ul><li>The purpose here is to avoid unnecessary complexity that will degrade performance. </li></ul>
    4. 4. P A SS MADE <ul><li>Availability Requirements </li></ul><ul><li>Availability is a measure of time a system or component is online ready to perform its specified function. </li></ul><ul><li>It is easy to ask for 99.9% but is it needed? Meeting the requirement will come at a cost. </li></ul><ul><li>Analyze: </li></ul><ul><ul><li>Who do you expect your customers to be? What are their expectations? </li></ul></ul><ul><ul><li>How much downtime is acceptable and at what times of day? Is a 15 minute offline window at 3am for backups acceptable? </li></ul></ul><ul><ul><li>Do internal company processes depend on the service? </li></ul></ul><ul><ul><li>What is the schedule and budget? </li></ul></ul>
    5. 5. P A SS MADE <ul><li>Availability Requirements </li></ul><ul><li>Common causes of applications becoming unavailable or unreliable: </li></ul><ul><ul><li>Inadequate testing </li></ul></ul><ul><ul><li>Change management issues </li></ul></ul><ul><ul><li>Lack of ongoing monitoring </li></ul></ul><ul><ul><li>Operational errors </li></ul></ul><ul><ul><li>Weak code </li></ul></ul><ul><ul><li>Interactions with external services or apps </li></ul></ul><ul><ul><li>Differing usage levels, peak overloads </li></ul></ul><ul><ul><li>Hardware failures </li></ul></ul>
    6. 6. PA S S MADE <ul><li>Security Requirements </li></ul><ul><li>The focus here is on recognizing current and future threats and developing measures that counteract real or implied threats. </li></ul><ul><li>Most security measures are based on: </li></ul><ul><ul><li>Authentication </li></ul></ul><ul><ul><li>Authorization </li></ul></ul><ul><ul><li>Data protection </li></ul></ul><ul><ul><li>Auditing </li></ul></ul>
    7. 7. PA S S MADE <ul><li>Security Requirements </li></ul><ul><li>Some possible policy requirements: </li></ul><ul><ul><li>Password policy </li></ul></ul><ul><ul><li>Logon policies and auditing </li></ul></ul><ul><ul><li>Intruder prevention processes </li></ul></ul><ul><ul><li>Ownership/responsibility for user accounts </li></ul></ul><ul><ul><li>Encryption policies </li></ul></ul>
    8. 8. PAS S MADE <ul><li>Scalability Requirements </li></ul><ul><li>The ability to increase system capacity by upgrading hardware and software without extensive modifications to the application software. </li></ul><ul><li>Only an issue for distributed applications. </li></ul><ul><li>Most issues are resolved during design and initial implementation. </li></ul><ul><li>During the requirements stage it is still necessary to look into what hardware and software changes are needed and the cost of scaling it over time. </li></ul><ul><li>Optimizing for Scalability can conflict with maximizing for Performance. </li></ul>
    9. 9. PAS S MADE <ul><li>Scalability Requirements </li></ul><ul><li>Scaling Up: </li></ul><ul><ul><li>Achieving scalability by using faster hardware </li></ul></ul><ul><ul><li>(single machines) </li></ul></ul><ul><li>Scaling Out: </li></ul><ul><ul><li>Achieving scalability by using more hardware (multiple machines) </li></ul></ul>
    10. 10. PAS S MADE <ul><li>Scalability Requirements </li></ul><ul><li>Key factors that affect scalability (in order of decreasing impact): </li></ul><ul><ul><li>Requirements and design (most impact) </li></ul></ul><ul><ul><li>Code tuning </li></ul></ul><ul><ul><li>Product tuning </li></ul></ul><ul><ul><li>Hardware tuning (least impact) </li></ul></ul>
    11. 11. PASS M ADE <ul><li>Maintainability Requirements </li></ul><ul><li>Your application should be designed to be easily be maintained and repaired. </li></ul><ul><li>Example maintainability requirements: </li></ul><ul><ul><li>An episode of unexpected downtime will not exceed 5 minutes. </li></ul></ul><ul><ul><li>Scheduled maintenance downtime will not exceed 5 days a year during non peak hours. </li></ul></ul><ul><ul><li>Scheduled maintenance should not exceed 4 hours at a time. </li></ul></ul>
    12. 12. PASS M ADE <ul><li>Maintainability Requirements </li></ul><ul><li>Example objectives of maintainability requirements: </li></ul><ul><ul><li>Ensure that minor defects in an application are easy to correct. </li></ul></ul><ul><ul><li>Ensure that minor enhancements to an application are relatively easy to implement. </li></ul></ul><ul><ul><li>Minimize maintenance costs and free up programmers for development rather than maintenance work. </li></ul></ul>
    13. 13. PASS M ADE <ul><li>Maintainability Requirements </li></ul><ul><li>Key factors affecting maintainability requirements are: </li></ul><ul><ul><li>Breadth of application – no of sites </li></ul></ul><ul><ul><li>Method of distribution/deployment </li></ul></ul><ul><ul><li>Maintenance expectations </li></ul></ul><ul><ul><li>Impact of 3 rd party agreements </li></ul></ul>
    14. 14. PASS M A DE <ul><li>Accessibility Requirements </li></ul><ul><li>This is, providing equal access to all users including people with cognitive and physical disabilities. </li></ul><ul><li>Some guidelines: </li></ul><ul><ul><li>Use accessibility features in areas that affect large number of users </li></ul></ul><ul><ul><li>Incorporate accessibility features in parts of application users frequently or integrally used. </li></ul></ul><ul><ul><li>Ensure application is compatible with accessibility aids. </li></ul></ul><ul><ul><li>Check local legislation affecting the application. </li></ul></ul><ul><ul><li>For web applications, follow W3C recommendations. </li></ul></ul>
    15. 15. PASS MA D E <ul><li>Deployment Requirements </li></ul><ul><li>Who are your users? </li></ul><ul><li>Where are they? </li></ul><ul><li>How do you intend to deploy you application to them? </li></ul><ul><li>Users can usually be separated into 3 categories: </li></ul><ul><ul><li>Standalone users </li></ul></ul><ul><ul><li>(ie not LAN connected) </li></ul></ul><ul><ul><li>Remote access users </li></ul></ul><ul><ul><li>Local network users </li></ul></ul>
    16. 16. PASS MA D E <ul><li>Deployment Requirements </li></ul><ul><li>Factors in the deployment strategy are the range of OSs, configurations of users computers and specifications of connecting network infrastructure. </li></ul><ul><li>How should the application be distributed? Some scenarios: </li></ul><ul><ul><li>Large number of users in diverse locations - </li></ul></ul><ul><ul><li>CD media </li></ul></ul><ul><ul><li>Smaller number of users – Internet or Intranet based download </li></ul></ul><ul><ul><li>Users located worldwide – Over internet with </li></ul></ul><ul><ul><li>different packages for different languages </li></ul></ul>
    17. 17. PASS MAD E <ul><li>Extensibility Requirements </li></ul><ul><li>This is the degree to which an application can be enhanced in the future to meet changing requirements. </li></ul><ul><li>An example objective might be to ensure future enhancements can be easily and quickly implemented. </li></ul><ul><li>Extensibility can be tightly coupled with scalability so extensibility requirements should include the ability to enhance data, hardware and software components. </li></ul><ul><li>Think about the average time and cost it will take to make updates in different areas of the application. </li></ul>
    18. 18. Operational Requirements <ul><li>Further Reading </li></ul><ul><li>This presentation was based heavily on these sources: </li></ul><ul><ul><li>Book: MCSD .NET Solution Architectures </li></ul></ul><ul><ul><ul><li>By Randy Cornish, Thomas Moore, Don Pavoni </li></ul></ul></ul><ul><ul><ul><li>and Eric Rockenbach </li></ul></ul></ul><ul><ul><li>Blog: DotNetJohn </li></ul></ul><ul><ul><ul><li>http:// www.dotnetjohn.com/articles.aspx?articleid =111 </li></ul></ul></ul><ul><ul><li>Blog: David DeWinter </li></ul></ul><ul><ul><ul><li>http://blogs.rev-net.com/ddewinter/2006/10/21/%C2%BB-pass-made-part-1-of-2/ </li></ul></ul></ul>Twitter: gregmalcolm [email_address] Blog: http://geekswithblogs.net/gregorymalcolm