SSE - Oral Exam Flashcards
(45 cards)
What are some elements of a PID?
o Finding out and defining the problem to be solved
o Give the project a name
o ID the project sponsor (name, contact info)
o ID the business need – problem being solved
o ID the user roles
o ID high level user requirements
o ID the expected value (feasibility analysis)
Does the system contribute to the overall objectives of the organization?
Can the system be implemented using current technology and within given cost and schedule?
Can the system be integrated with our systems which are already in place?
Tangible and intangible values
o ID any special issues
4 ways to determine the expected value (feasibility analysis)
Does the system contribute to the overall objectives of the organization?
Can the system be implemented using current technology and within given cost and schedule?
Can the system be integrated with our systems which are already in place?
Tangible and intangible values
What are elements of software requirements?
o Finding out and defining what is required (functionality and constraints) of the software
o Analyze current situation precisely as possible
o Deliver what software client needs
o Design UI
o Create domain model (analysis model)
o Create requirements spec (SRS) – ensure correct
3 elements of an SRS - ensure correct
Legal document
Specifications must not be ambiguous, incomplete, or contradictory
Must not have phrases like “optimal” or “98% complete”
Software Engineering definition
• An application of the systematic, disciplined, and qualitative approach to the development, operation, and maintenance of software, or the study of.
o Systematic – done or acting to a fixed plan; methodical
o Disciplined – showing a controlled form of behavior or way of working
o Quantifiable – capable of being measured
Generic phases of the software lifecycle
Identification and Definition
o Define the problem, scope, needs of the customer, the risks, finding
Software requirements
o The functions required, the existing environment, any new software or application needed
Software design and implementation
o Develop and test
o Can be done in iterations
o May include regression testing after each iteration
Software validation
o Ensures the product follows the requirements and specifications outlined in the first step
o Test and regression testing
o Make sure meets the specs and the customer’s needs
Deployment and evolution
o Hand over to the customer
o Maintenance
o Training
o Updates or changes
General principles of the software engineering process (10)
- Determine the value
- KISS
- maintain a clear vision
- keep in mind that someone else will need to understand what you are doing or have done
- Plan on reuse
- think before acting
- Things change
- Design to meet those changes
- Plan ahead
Key actions of Elicitation
o Identify the product’s expected user classes and other stakeholders
o Understanding user tasks and goals and the business objective with which those tasks align
o Learning about the environment in which the new product will be used
o Working with individuals who represent each user class to understand their functionality needs and their quality expectations
What are some Elicitation methods?
Workshops / JAD - joint application design Focus groups Observations Questionnaires System interface analysis User interface analysis Document analysis Prototyping
System interface analysis
o Analysis of other connecting systems
o Identifies data exchange formats
o Identifies functional requirements
User interface analysis
o Analysis of existing UI
o Identifies user requirements
o Identifies functional requirements
o User-interface requirements
Special type of non-functional requirements, which addresses the user interface
Describes the look and feel of the product.
• “The system shall allow user interaction via a touch-screen.”
• “The system shall be judged by 75% of users to be user friendly.”
• “The system shall be ADA compliant.”
Document analysis
o Examine the documents that are currently being used – they help identify data elements and processes
o Existing documentation can help reveal how systems currently work or what they are supposed to do
o Can help identify functionality that needs to remain, or isn’t used.
o Can help identify how people do their jobs currently, what competitors offer, and what vendors say their software should do
4 steps to create use case documentation
- Identify the actors in the system
- Identify use cases
- Create use case descriptions
- Create scenarios
Business requirements
Are why the implementation is needed. The business needs the organization hopes to achieve
User requirements
The tasks and goals the user must be able to perform that will provide value to someone. They’re what the user will be able to do
Features
• These requirements consist of one or more logically related system capabilities that provide value to a user and are described by a set of functional requirements
- A feature is typically a set of requirements
- They can be represented using a feature tree
Analysis Model Elements (4)
System Model
o Represents a high-level view of the system architecture and the actors
Data Model (class diagram) o The domain objects and their relationships
Functional Model (sequence diagram) o The operations that transform data
Behavioral Model (state-machine diagram) o The behavior of the system
System modeling - use case
- Use a package to represent the system
- Show the actors and their relationships
- Show the information flow
- Use stereotypes where appropriate
6 signs that requirements are stabilizing when
- Users can’t think of new use cases
- New scenarios don’t lead to new functional requirements
- Users are repeating issues already addressed
- Suggested features, user requirements, or functional requirements are out of scope
- New requirements are all low priority
- Developers and testers raise few questions when reviewing requirements
High Level Sequence Diagram
- Can be used to analyze user interactions with the system
* Shows the time ordering of the interactions between the user and the system
Characteristics of a good requirements document (8)
- Correct – every requirement stated is one that the software shall meet
- Unambiguous – every requirement has only one interpretation
- Complete – all significant requirements; definitions of all responses to all input data; full labels and references
- Consistent – must agree with higher level documents
- Ranked for importance and/or stability – each requirement has an identifier to indicate the importance or stability of that requirement
- Verifiability – every requirement is verifiable (testable)
- Modifiable – the structure and style of the SRS can be changed easily
- Traceable – the origin of each requirement is clear and facilitates the referencing of each requirement in future documentation
Functional requirements
o Describes the computational operations of the system in terms of its inputs, outputs, and actors.
o Describes required behavior in terms of required activities, such as reactions to inputs, and the state of each entity before and after an activity occurs. – Pfleeger & Atlee
What are Non-functional requirements?
o Describes some quality characteristic that the software solution must possess. – Pfleeger & Atlee
o Define the overall qualities or attributes of the resulting system. – K & S
o Taxonomy - Sommerville
Formal methods
A particular kind of mathematically rigorous techniques for the specification, development and verification of software and hardware systems
- Involve complex math and proofs rather than ambiguous language
- A modeling language (e.g. Z) is used, which makes this an expensive and sometimes complicated process
- The testing involves proofs as part of the testing
- Best for critical projects such as safety
- Requires a developer experienced in the language
