Skip to main content

Home/ Coders/ Contents contributed and discussions participated by Kevin O'Neill

Contents contributed and discussions participated by Kevin O'Neill

Simple Middle Filter: All | Bookmarks | Topics
Kevin O'Neill

The 7 Software "-ilities" You Need To Know - 0 views

www.codesqueeze.com/tware-ilities-you-need-to-know

engineering ilities requirements software

shared by Kevin O'Neill on 13 Aug 08 - Cached
  • 1. Usability Software usability can be described as how effectively end users can use, learn, or control the system
  • 2. Maintainability ( or Flexibility / Testibility) The definition of maintainability [for me] implies how brittle the code is to change
  • 3. Scalability Scalability is the ability for your program to gracefully meet the demand of stress caused by increased usage
  • ...4 more annotations...
  • 4. Availability (or Reliability) How long the system is up and running and the Mean Time Between Failure (MTBF) is known as the availability of a program
  • 5. Extensibility Are there points in the system where changes can be made with (or without) program changes?
  • 6. Security I shouldn’t need to go into this one but to be thorough I like this definition of security: the measure of system’s ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users.
  • 7. Portability Portability is the ability for your application to run on numerous platforms.
Kevin O'Neill

In Search of Excellent Requirements - 1 views

www.processimpact.com/...exc_reqs.html

engineering requirements software

shared by Kevin O'Neill on 13 Aug 08 - Cached
Rick Fan and Kevin O'Neill liked it
  • Consequently, it is not reasonable to expect us to make sound business or technical decisions on behalf of the customers, or to resolve conflicting requirements supplied by different end users, or to set priorities for the many requirements that might be collected.
  • We have finally reached the state where if no project champion can be found to see that the right system is built, we cancel the project.
  • The consequence of not explicitly discussing these quality tradeoffs is a surprise upon delivery, when the customer finds that his implicit quality attribute requirements have not been achieved
  • ...3 more annotations...
  • One way to reach an appropriate middle ground in the specification process is to conduct formal inspections of the SRS. A structured document like the IEEE SRS is readily inspected by the design team, the project champions, other representative users, and other software engineers who are not directly involved with the project
    • Kevin O'Neill
      Kevin O'Neill on 13 Aug 08
       
      sadly, this is something that is always left to the end to 'clean up'. Meaning, the spec is complete when the project is delivered versus kept up to date and in sync with what we are delivering.
  • A prototype is intended to answer specific questions about functionality or interaction styles. If you don't have any questions, don't bother with a prototype
  • Even in a small software group, a focus on accurately and completely capturing, documenting, and modeling the user requirements is a major contributor to building high quality information systems
1 - 0 of 0
Showing 20▼ items per page