Strategy vs tactics

Strategy: the overall plan, the final purpose (What?)
Tactics: the actual means used to meet an objective (How?)
The strategy is an idea, the tactics is an action taken to execute the strategy

Efficient vs effective

Effective is doing the right thing.
Efficient is doing it in the optimal way.
Efficient and effective: doing the right thing in the optimal way.

Functional vs non-functional requirements

Functional: what the system should do
Non-functional: how the system should be
Utility: fit for purpose.
Warranty: fit for use.

Business vs Functional analysis

The business analyst is responsible for the business requirements; it reports to the Business. Answering more to questions like “What?” needs to be done, based on the business “Why?” it needs to be done.
The functional/technical/systems analyst takes the “What?” from the business analyst, and they are translating it into the “How?”.
The Business Analyst gets the requirements and the Functional Analyst looks at how the technical solution can be best used to meet those requirements.

SOA vs SaaS

Service Oriented Architecture (SOA) is a software architecture design pattern based on distinct pieces of software providing application functionality as services to other applications. This is known as service-orientation. It is independent of any vendor, product or technology.
Software as a service (SaaS) is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted.

There are six main programming paradigms: imperative, declarative, functional, object-oriented, logic and symbolic programming (wikipedia).
Read more about declarative vs imperative programming

Remember the 12 principles behind the Agile Manifesto? They start with:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

– http://agilemanifesto.org/principles.html

I think they are much easier to be remembered in a mindmap format. I split them in two parts: half of them refer to teams, while the other half refers to the work. The result is below:

Agile Principles Mindmap – done with SimpleMind+ for iOS http://www.simpleapps.eu/simplemind/

In fact, I needed a reason to upload a high resolution image under the new theme 🙂

Functional vs non-functional requirements

Functional: describes the behavior of the system, its functionality; what the system should do
Non-functional: describes the performance characteristics of the system; how the system should be

Functional: the system must present the user an interface with the number of records in the db.
Non functional: the number of records must update in real-time.
—
Functional: the system must send an email when a new order is placed.
Non-functional: the emails should be sent with a latency of no greater than 10 minutes from such an activity.

Use cases

Use cases represent a practice for capturing functional requirements.

Use cases > scenarios:

A use case defines a goal-oriented set of interactions between external actors and the system under consideration.
A scenario is an instance of a use case, and represents a single path through the use case.
Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals.
– http://www.bredemeyer.com/pdf_files/functreq.pdf

Scenarios > use cases:

A scenario is a sequence of steps describing an interaction between a user and a system.
A use case is a set of scenarios tied together by a common user goal.
– Martin Fowler – UML distilled

In order to engage all the stakeholders, the use cases should be:
– written in an easy to understand language
– kept short (1-2 pages max)
– have a narrative language (user stories)
– have a clear structure (Title, Goal, Actors, Assumptions, Steps, Variations, Non-functional requirements, Issues)