This note collect all terms occur in SEPP Lecture 6/7/9. It would be helpful to recap what has learnt and what has already been abstracted away.
Pool of atomic terms
plan-driven development process, heavy documentation, formal documentation, iteration, agile development process, individual, interaction, working software, customer collaboration, responding to change, design, implementation, unfinished feature, requirement engineering, requirement specification document, omnipresent, details
software project, long-lived system, software product, developing team, small-medium sized system, several potential customer, speedy delivery, feature
elicitation, interview, survey, facilitated meeting, informal user analysis, informal user discussion
persona, personalisation, name, personal circumstance, stock photograph, job, education, background, technical skill, experience, relevance, shared vision, key system feature
scenario, narrative, context, user, perspective of the user, real users, role, responsibility, high-level scenario, use-case scenario, brief statement, overall objective, activity, current system, identified problem, specific details, reality, team member, user, expert, brainstorming, shared understanding, facilitate communication, design creativity, specification
user story, sequence of interaction, format
trade-off, simplicity, functionality, familiarity, novelty, automation, control, feature creep, action, action verbs, phrases, simple list, input, action, output, description, constraint, comment, user needs, options
output, model, UML, Simulink, graphical model, executable model, written document, record reasons, decision, good design, known requirement, future requirements, implementers, existing technology, reusable components, human angle, situation-dependency, OO design, functional design, OO programmer, functional programmer, design choices, future changes, different levels, subsystems, classes, responsibility, interface, message, order
architecture, fundamental influence, non-functional characteristics, non-functional attribute, component, database, maintainability, resilience effect, fundamental organization, software system, component, relationship, environment, principles, design, evolution, related system, named software unit, coherent set of functionality, collection of services, coherent unit of functionality, module, named set of components
architectural design, product lifetime, software reuse, number of users, software compatibility, planned schedule, team capacity, budget, large-scale components, cross-cutting concerns, major concern, complexity, local data, separation of concerns, related functionality, implement once, stable interface
distribution architecture, client-server architecture, web-based software product, mobile software product, client, load balancer, server, web, database, Model-View-Controller pattern, MVC, multi-tier client server architecture, object-oriented approach, shared database, structured data, concurrent update, business system, local servers, service-oriented architecture, change regularly, scalability, resilience to failure, peer to peer architecture, message bus architecture
technological consideration, database, delivery platform, server, open source platform, development technology
detailed design, design principle, class diagram, cohesion, understandability, maintainability, reliability, coupling, abstraction, encapsulation, information hiding, separation of interface, separation of implementation, public interface, decomposition, modularisation
Key linkage between atomic terms
- term ‘feature’ aims to distinguish from ‘requirement’ coming from a customer (in software project), but similar in meaning.
- personas will overlap, Sommerville advises using max 5 personas.
- software product are recommended to use high-level scenario, different to use case scenario.
- team member works individually on a subset of scenarios.
- get user involved in the development.
- Sommerville recommends using 3-4 scenarios/persona.
- requirement need to be: independent, coherent, relevant.
- user stories may immediately suggest requirements.
- start by using product, but then think creatively about other/additional more efficient and interesting options.
- design is the process of deciding how software will meet the requirements. Usually exclude detailed coding level.
- maintainability vs performance
- security vs usability
- availability vs time to market and cost
- major concern of designing architecture is complexity due to the number of components and their relationship, the latter increasing exponentially.
- multi-tier client-server architecture is a client-server system with a shared database.
- technologies need to be decided, since architectural design, as changing them later is difficult and expensive.
Rule to categorize atomic terms
- How close they link with others.
- Are they belong to some existing categories.
- No need to explicitly classify all these terms into different groups.