When talking about requirements, SMART refers to the following qualities:

• Specific
• Measurable
• Achievable
• Relevant
• Timeboxed

Specific

Specific requirements are ones that pair a vague feature (e.g. The user can search for a movie) with a specific qualifier (e.g. by its title).

Measurable

Making a requirement measurable ensures that it is testable. For instance, we may have a requirement that an end-to-end response time for a feature should be less than 3 seconds.

Achievable

Achievable requirements are those that can be completed in a single sprint or iteration. Larger requirements can be made achievable by breaking them into smaller components.

Relevant

A requirement is relevant when it has business value to stakeholders. In order to drill down to what is most important for stakeholders, asking the “Five Whys” is key.

Timeboxed

Development on a requirement is timeboxed–all work stops at the end of the sprint. If the requirement was unachievable, the remaining work can be rescheduled as a new story. If necessary, the requirement can be further broken down into smaller requirements that are attainable. It is also possible to scrap the requirement.

Crafting good requirements or user stories means adhering to these SMART guidelines.

FIRST properties refer to the software testing properties:

• First
• Isolated/dependent
• Repeatable
• Self-validating
• Thorough/Timely

Fast

This is the idea that we want a quick feedback loop. If our tests aren’t fast, we won’t want to run them often. If we don’t run tests often, it becomes harder to isolate problems since we may have introduced several new additions to our code since we last ran our tests.

Isolated and Dependent

Tests should only invoke the method under testing. Other functionality should be stubbed out and asserted. By building the necessary state for your test case, it becomes easier to understand the situation that your test case describes.

Repeatable

Tests should have deterministic results. If test results are highly variable, then they are not reliable. The results of tests should not be affected by the order in which they are called or how many times they are run.

Self-Validating

This is the concept that tests should be able to automatically resolve whether a test has passed or failed. We shouldn’t have to manually inspect the results to determine a pass/fail.

Thorough/Timely

A test suite should do a thorough enough job in covering test cases in order to be confident enough to push the code to production.

Through test-driven development (TDD), writing test cases first can aid in making testing itself timely (i.e. when you need them!) If you let your test cases guide your implementation, you repeatedly test until you meet the expected functionality/behavior.

Additional Resource: https://hackernoon.com/test-f-i-r-s-t-65e42f3adc17

Test Driven Development (TDD) is about developing tests for your application’s functionality before actually writing any code. In this way, your tests guide how you approach implementation.

A mock is a way of stubbing functions/methods that you may or may not have developed yet and providing mock data and results for those functions. In this way, you are able to isolate testing on one defined function that depends on those stubbed out functions. This way, you can isolate any problem to the function you are testing without worrying about implementing those other functions OR (if those functions are already implemented) errors introduced from those other functions.

Before starting this course, much of my understanding about software engineering came from my summer internship with Qualcomm and my current internship at Achieve Internet. Software engineering is a way of applying engineering principles to software development in order to maximize software’s business value. There are several methods of doing this, as our text explains.

During my time at Qualcomm, I helped manage a product being developed by a business intelligence team in Hyderabad, India. We used Agile to develop product stories that would result in incremental prototypes.

But I also gained exposure to the Waterfall software development cycle while at Qualcomm in developing my own project — a RESTful web API. My mentor and I chose this development cycle so I could a) be exposed to multiple software development lifecycle methods and b) be able to take a good 6-8 weeks to scope out my project and develop a first working prototype (this choice was due to the length of my internship).

Since I’ve started interning at Achieve Internet, I have also been exposed to the Spiral development model and how the various people at Achieve (Project Manager, DevOps engineer, developers, etc) play a role at different points of this model.

While my definition of software engineering hasn’t changed since reading the text, I appreciate the solidification and verification of my existing knowledge and experience. I am looking forward to this class!