Software Developers Flashcards
1.Can you name a number of non-functional (or quality) requirements?
In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture.
Broadly, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of “system shall do “, while non-functional requirements are “system shall be “.
Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are “constraints”, “quality attributes”, “quality goals”, “quality of service requirements” and “non-behavioral requirements”.[1] Informally these are sometimes called the “ilities”, from attributes like stability and portability. Qualities, that is non-functional requirements, can be divided into two main categories:
- Execution qualities, such as security and usability, which are observable at run time.
- Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.[2][3]
Examples
Accessibility
Audit and control
Availability (see service level agreement)
Backup
Capacity, current and forecast
Certification
Compliance
Configuration management
Dependency on other parties
Deployment
Documentation
Disaster recovery
Efficiency (resource consumption for given load)
Effectiveness (resulting performance in relation to effort)
Emotional factors (like fun or absorbing)
Environmental protection
Escrow
Exploitability
Extensibility (adding features, and carry-forward of customizations at next major version upgrade)
Failure management
Fault tolerance (e.g. Operational System Monitoring, Measuring, and Management)
Legal and licensing issues or patent-infringement-avoidability
Interoperability
Maintainability
Modifiability
Network topology
Open source
Operability
Performance / response time (performance engineering)
Platform compatibility
Price
Privacy
Portability
Quality (e.g. faults discovered, faults delivered, fault removal efficacy)
Recovery / recoverability (e.g. mean time to recovery - MTTR)
Reliability (e.g. mean time between failures - MTBF)
Reporting
Resilience
Resource constraints (processor speed, memory, disk space, network bandwidth, etc.)
Response time
Robustness
Safety or Factor of safety
Scalability (horizontal, vertical)
Security
Software, tools, standards etc. Compatibility
Stability
Supportability
Testability
Usability by target user community
2.What is your advice when a customer wants high performance, high usability and high security?
My “advice” starts with the questions: “What do you consider X to be?” where X belongs to the set {“high performance”, “high usability”, “high security”}. I might offer that I consider “high performance” to be a misnomer, as it’s either acceptable or not, and that unless the customer defines it, I don’t know how we’d even attempt to measure something as vague as “usability.”
I’m not sure where I’d prepare for this question. Any suggestions are appreciated.
3.Can you name a number of different techniques for specifying requirements? What works best in which case?
I can name several: tell me in person, tell me over email, tell me over IM or over the phone. I know that’s not what you’re looking for. You’re looking for answers like “use cases.” It all boils down to the same. I might even mention “unit tests” here. That’s part of the spec, as far as I’m concerned, and for almost any software I write for myself, it’s the only way I specify requirements (except for maybe a very informal to-do list).
Face-to-face works best in most cases, I’d gather.
The answer after doing some research: ¡Ay, ay, ay, no me gusta! I didn’t see this coming. There are a number of things that could qualify as answers (Prototyping, Storyboards, Modeling, …, State transitions) that I knew about beforehand. I thought to include none of them.
4.What is requirements tracing? What is backward tracing vs. forward tracing?
b
5.Which tools do you like to use for keeping track of requirements?
/
ow do you treat changing requirements? Are they good or bad? Why?
.
7.How do you search and find requirements? What are possible sources?
.
8.How do you prioritize requirements? Do you know different techniques?
.
9.Can you name the responsibilities of the user, the customer and the developer in the requirements process?
.
10.What do you do with requirements that are incomplete or incomprehensible?
.
